1. 01 Apr, 2021 2 commits
  2. 31 Dec, 2020 1 commit
  3. 31 Oct, 2020 1 commit
  4. 30 Oct, 2020 2 commits
    • Jonathan Wilkes's avatar
    • Jonathan Wilkes's avatar
      snap to closest grid line until we've travelled half the distance to the next · fc2f67c4
      Jonathan Wilkes authored
      This gives what is to me smoother and more predictable snapping motion with
      respect to the current mouse position.
      For example-- imagine the grid cell size is 10 and the selected object under
      the mouse already has its top left corner aligned with vertical grid line #2.
      If I begin dragging that object to the left, within a single pixel of motion
      it will snap to vertical grid line #1 which is 9 pixels away from the
      object's current position.
      With this commit, the user must drag the object cellsize / 2 pixels before it
      snaps to a new position.
      To me this seems smoother as it rounds to the nearest grid line rather than
      to the grid line with the smallest coordinate value.
  5. 29 Oct, 2020 1 commit
    • Jonathan Wilkes's avatar
      allow different grid sizes (factors of 100 for now, but easily changed) · 6dc3d006
      Jonathan Wilkes authored
      We also keep a partially transparent version of a grid for editmode. This
      allows us to keep editmode visually distinct from runmode, even if snap-to-grid
      isn't turned on.
      If needed it's pretty easy to make the following changes:
      * set the "big" cell size to something that isn't 100 (but I'm not sure how
        much control over the grid we actually want to give users-- e.g., setting
        the big cell to something for which the small cell isn't a factor
      * allow snap-to-grid to be set independently for each canvas. (But again,
        what would be the use case for this?
  6. 07 Oct, 2020 1 commit
  7. 06 Oct, 2020 2 commits
    • Ivica Bukvic's avatar
      Proper closure to the glist_grab saga in respect to iemgui numbox · 3b43f5db
      Ivica Bukvic authored
      * Reenabled the mouseup event that was mysteriously disabled for an unknown amount of time. This made it difficult to report to the object mouse release event after it has been dragged and the mouse ended-up being positioned outside object's bounds.
      * This now allows for very nice control over objects that are being grabbed.
      * Mouse release sets doubleclick flag to -1 to differentiate itself from the regular mouse movement which also reports mouse press as 0.
      * Allowed for glist_grab to be exclusive in respect to key presses and settable as such via the glist_grab call. See iemgui numbox for benefits of this implementation, described below.
      * Completely reworked numbox logic with additional variables designed to improve code readability and disambiguate the x->x_gui.x_changed and x->x_gui.x_change.
      * Rotated the order of event propagation to have glist_grab 1st and event bound objects second (e.g. key/keyname etc.). THIS IMPLEMENTATION SHOULD BE HEAVILY SCRUTINIZED TO MAKE SURE THERE ARE NO ADVERSE EFFECTS. Given the rapid release cycle I suggest adding it to the next release and then observing user feedback.
      * The numbox now offers the following behavior:
      1) click and drag and release (with or without shift which can be pressed at any time to toggle between fine +-0.01 and +-1 increments) which immediately changes the number value and outputs it. This kind of grab does not do exclusive keyboard grab and therefore allows keyboard to still propagate to other bound events.
      2) click and immediately release enters the exclusive keyboard mode and makes the '>' appear to make the user aware of this. Here you can use arrows up/down with and without shift, press allowed keyboard keys (numbers, enter, delete, etc.) and edit the value accordingly. Pressing arrows always changes the last digit of the currently truncated number. Pressing enter commits the value and retains the focus for another 3 seconds unless user presses Esc or clicks outside the number box. If all the digits are erased the number implicity assumes 0.
      3) clicking and immediately releasing without shift pressed to activate exclusive keyboard mode activates legacy/default behavior where entered text overwrites the existing (the cursor starts at the beginning and initially only has '>'). Doing the same with shift key puts the numbox in the append mode where one can continue adding to the previously committed number. This is even true if the displayed number is simply '+' or '-' due to it exceeding the number box width (not including decimals).
      4) Values whenever committed are clipped to the object's min and max and reflected as such in the number object. If the object remains activated, the number is not clipped if it exceeds the object's length, but shows only last n visible digits. Upon removing focus (activation), it redraws from the beginning (if number of digits exceeds the width but does not exceed the min/max thresholds. Re-activating the object redraws it with the last digits visible.
      * All glist_grab instances in externals should be taken care of and are, by default, not exclusive.
      * Still TODO: checking if vanilla numbox is working ok. The rest of the objects shoould be unaffected.
    • Ivica Bukvic's avatar
      Retracing steps to enable holistic mouse action tracking via glist_grab · a20427d0
      Ivica Bukvic authored
      * Lots of debugging stuff lying around.
      * A significant rewrite of the prior iemgui numbox behavior to capitalize on the exclusive grab opportunity.
  8. 02 Oct, 2020 4 commits
  9. 30 Sep, 2020 1 commit
    • Ivica Bukvic's avatar
      Introduced new activated msg border drawing approach · 3cacb1f3
      Ivica Bukvic authored
      * Got rid of the problematic svg background which marginally worked on 0.14.7 but doesn't on 0.24.4
      * Instead, using the existing msg border/background and adjusting its size dynamically
      * The behavior remains identical to before (hide nlets, do not worry about readjusting patch cords)
      * LATER: think about integrating patch cord and nlet adjustment to match vanilla behavior, consider further fine-tuning the text placement based on various zoom levels and fonts sizes (some still are a pixel off, this is true for also regular text objects), and finally implement this same approach for the regular text objects
  10. 23 Sep, 2020 1 commit
  11. 22 Sep, 2020 5 commits
  12. 21 Sep, 2020 2 commits
    • Albert Gräf's avatar
      Fix up the dummy canvas environment in abstracthandler_callback. · 65647f90
      Albert Gräf authored
      Instead of casting a magic number to a pointer, which is a sure recipe
      for disaster, provide a properly initialized dummy t_canvasenvironment*
      pointing to static storage.
    • Ivica Bukvic's avatar
      Fixed asynchronoous getscroll and activate regression · b06ca0de
      Ivica Bukvic authored
      * This was caused by the improvement in the scrolling algorithm earlier this summer to throttle down getscroll calls invoked by arrays that resulted in CPU intensive redraws. As it turns out, the same also up until this patch prevented the following from working properly:
      1. select text object and displace it by dragging using a mouse until it goes partially outside the canvas edge
      2. the object is activated at a location before getscroll changes the viewport settings to ideally fit everything within the window
      3. getscroll is called and everything is relocated except the activated box because its current implementation is oblivious to the changes in canvas positioning.
      4. as a result the activated box does not match the actual object position.
      * The new patch addresses this by introducing a synchronous scroll request that has no delays and executes immediately, thereby completing canvas relocation before the activated box is drawn. Due to its potential to be misused causing high CPU usage, this call is currently reserved only for this special case.
      * LATER: consider ensuring that activated boxes are also relocated on getscroll, so that in the case of scripted changes to the viewport activated boxes remain in a correct place. Even so, this should not be seen as a workaround but as a feature that may prove useful in other contexts. So, the solution is to have both this patch and this other thing eventually implemented.
  13. 20 Sep, 2020 1 commit
  14. 14 Sep, 2020 1 commit
  15. 13 Sep, 2020 5 commits
    • Albert Gräf's avatar
    • Albert Gräf's avatar
      Make Alt the key to temporarily change to run mode. · 2517cfab
      Albert Gräf authored
      In one fell swoop, this solves all usability issues we have with the
      Ctrl key we currently employ for that purpose, which interferes with all
      our menu keybindings, and makes temporary run mode unusable on the Mac.
    • Albert Gräf's avatar
      Fix the findbox regression, part 3. · 1747a89e
      Albert Gräf authored
      Make Ctrl+F work if the canvas is in edit mode. In this case,
      canvas_key(), upon receiving the Ctrl keydown event from the Ctrl+F
      shortcut, temporarily switches to run mode, but never gets the
      corresponding keyup event which goes to the findbox, so temporary run
      mode remains in effect when the findbox opens.
      This shouldn't actually be much of a problem, but the real trouble is
      that while canvas_key() informs the GUI about the change to run mode, it
      doesn't update the state of the canvas-local gl_edit variable
      accordingly. So when dofind() switches on edit mode later, the engine
      still thinks that it's in edit mode and thus doesn't trigger the
      necessary update.
      The easy fix is to just update gl_edit in canvas_key() when edit mode is
      temporarily disabled.
    • Albert Gräf's avatar
      Fix the findbox regression, part 2. · 12ab314b
      Albert Gräf authored
      This gets rid of some race conditions in the find operation, by ensuring
      that edit mode is only updated *after* mapping a subpatch window.
      This bug manifested itself when searching for objects in subpatches
      which are not visible at the time the find operation gets invoked. In
      this case, on the GUI side we both have to create the subpatch window
      and put it in edit mode. In the previous implementation these two
      operations would be executed separately and asynchronously. The end
      result was that usually the latter operation setting the edit mode in
      the GUI would win out, and the edit mode would later get overwritten
      again when the window was created.
      We fixed that race condition by ensuring that the engine is queried for
      its current edit mode status after creating a canvas window. The engine
      replies with a call to gui_canvas_set_editmode() in the GUI and thus the
      edit mode in the GUI now properly reflects the status in the engine
      after a window is mapped.
      TL;DR: This fix should now make sure that edit mode on the GUI side
      reflects that of the engine at all times.
    • Albert Gräf's avatar
      Fix the findbox regression, part 1. · df2fd7fd
      Albert Gräf authored
      This makes Ctrl+F work again, by making sure that edit mode is set
      correctly in the GUI even if glob_ctrl is set (because the Ctrl key up
      event goes to the find box and is thus is never received by the canvas).
  16. 09 Sep, 2020 4 commits
  17. 06 Sep, 2020 1 commit
    • Ivica Bukvic's avatar
      Dialog and other GUI improvements · f03e0459
      Ivica Bukvic authored and Albert Gräf's avatar Albert Gräf committed
      * Created new and hopefully improved dialogs that should work on all
        three OSs. These include improved margins, optimal sizes that account
        for OS-specific idiosyncrasies, use of non-native toplevel window
        titlebars that cause bunch of issues (e.g. ability to maximize a
        dialog window since nw.js, at least in the earlier versions, has
        spotty support for disabling those), fixed window sizes with minimal
        scrollbars where appropriate, proper spacing between items, better
        positioning of the checkbox and radio buttons, etc.
      * Enabled CTRL+W for the search dialog.
      * Improved and consistent find bar appearance on all windows (console,
        patch, search).
      * Refined activated box to match different zoom levels and font
        sizes. Small discrepancies still exist when using both custom fonts
        and zoom levels, but these are now no more than pixel off, whereas
        before it was all over the place.
      * Made sure that patch windows on all OSs are exactly the same size,
        even w...
  18. 04 Sep, 2020 2 commits
  19. 03 Sep, 2020 1 commit
  20. 25 Aug, 2020 1 commit
  21. 24 Aug, 2020 1 commit