GitLab

Ivica Bukvic authored Sep 20, 2020 and Albert Gräf committed Sep 22, 2020

Broken implementation of grab focus improvement (to be migrated to linux because Windoze debugging is a joke)

Ivica Bukvic authored Sep 18, 2020 and Albert Gräf committed Sep 22, 2020

* Fun to know that canvas_key is called even when you are not inside a canvas...

Ivica Bukvic authored Sep 18, 2020 and Albert Gräf committed Sep 22, 2020

* This means an object has requested exclusive focus

add an alert system that notifies the user of the existence of unsaved edited instances of the abstraction he is editing or about to edit

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.

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.

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.

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).

Albert Gräf authored Sep 01, 2020 and Albert Gräf committed Sep 09, 2020

This is useful, in particular, to print out pointer values with the
%zx specifier, since it prevents the annoying format warnings when
using %zx with t_int.

Ivica Bukvic authored Aug 31, 2020 and Albert Gräf committed Sep 06, 2020

* 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 when using custom zoom levels and fonts.

* Replaced the use of the legacy font menu with the native sub-menu and
  adjusted its behavior accordingly, including updating its values at
  patch open (the same method may prove useful in dealing with the
  undo/redo and other options not being registered properly because they
  may be running before the menu has been created).

* Refined the scrollbar behavior by providing a grab cursor when
  hovering and clicking on them. Also added dynamic updates to scrollbar
  colors (normal, hover, and click).

* Epic hack for making message boxes consistent size when activated.

* Made redrect on a GOP subpatch appear and disappear intelligently when
  dealing with subpatches populated exclusively with scalars. For
  instance, creating an empty object does not create a redrect yet
  because the user may be instantiating another instance of a
  scalar (e.g. a pony). However, once a non-data object has been created
  that wants to be displayed on the parent window inside GOP of the
  subpatch it is a part of, it toggles on. Similarly, once every
  non-scalar object has been deleted, the redrect disappears. There is
  still a lingering question why would one want to do this, but hey, who
  am I to judge?

* Fixed problem where a non-GOP text object got diagonal and y resize
  arrows that triggered consistency check.

* Fixed consistency check where resizing a GOP on the parent window
  using bottom-right corner cursor hotspots, triggered an error when the
  subpatch is also open. Now, everything resizes as it should
  concurrently, regardless of whether this is done on the subpatch or
  the parent window. As a bonus, the properties window reflects changed
  values regardless how they are being changed.

* Better iemgui number2 text offset across different font sizes and zoom
  levels.

* I think that is about it, although I may have missed something...

add mechanism that visually marks abstraction objects that are edited but unsaved, and all their ancestors

get rid of some compiler warnings introduced by the two new features (incompatible pointer type and implicit declaration)

Hopefully a better fix for the paste and clipboard paste crashers. Also a bit of reformatting of the indentation inside one of the functions that did not have consistent indentation. LATER: figure out why the front-end is not disabling options like paste at start-up.

Added comment to provide an update on an issue documented in the comments

First checkpoint in implementing custom scrollbars and improving the scrollbar behavior. This is a WIP that requires nw.js 0.46.2.

Finished second stage of the scrollbar implementation and added scrolling with middle click. All scrollbars are now operational and to the best of my knowledge accurate. The only things remaining are: getscroll needs to be called on deselect to recalculate when the handles are erased on objects that have them (we should get rid of these and focus on bboxes instead), responding to maximizing and restoring, and addressing a weird bug where in 0.46.2 patches are saved with larger window sizes under certain conditions.

Reverted scrolling by grabbing due to problematic relationship between scrollBy and the zoom factor

Continuing work on the scrollbars. The only known thing now remaining is ensuring that the patch window is properly recorded when saving it (under certain conditions it spits out completely wrong values

Removed debug printouts

Finished the scrollbars. The only thing remaining is for someone who has a better understanding of the pd_canvas.js and how the events are captured, to refactor my registration of events that ensure scrollbars are clickable and the onresize event. Currently, they are embedded inside the pd_canvas.js under the body tag where you will find both onscroll and onresize events.

Overhaul of the new scrollbars to further improve their behavior, enable as perfect of a fit of the plots both in gop and on toplevel, and dynamic updating of the plots in toplevel when resized. Reworked dynamic event adding/removal for the scrollbars and removed onscroll from the html document and moved it into the pd_canvas.js. Still need to add a delay for the backend callback to update the scrollbars on the toplevel plot/array and thereby remove scrollbar flicker.

Finished implementing the scrollbar callback and addressed popup not appearing in the right place (likely due to upgrade to 0.46.2)

Added names of arrays to their toplevel subpatch window title. Multiple arrays are listed in the order they have been added.

Another reworking of scrollbars to and array sizing to capture all possible scenarios. Some refactoring to make use of the canvas_hasarray. Remaining known issues pertaining to the plots are:
*array toplevel windows are not restored in position they were saved
*last element on the plots is not clickable
*make bezier plot look like bezier (may need to leverage curve_path)

Additional commenting to make it easier to catch-up with the Wagnerian function dealing with the key input sent by the front-end. Disabled check that prevented exiting from the edit mode when creating a new object via a keyboard shortcut on a canvas in a non-edit mode. Upon releasing CTRL, the edit mode was not initiated.

Proper fix for the nlet highlighting. Now allows for loose aiming and always starts the patch cord at the center of the outlet. Inlets from which we currently cannot connect from are grey when highlighted, while ones you can initiate connection from are orange (both colors are themeable inside the css). Also, if trying to connect an impossible connection (signal to non-signal), when hovering over the non-signal inlet during the connection cycle, such an inlet will be also highlighted gray (grey? whatever...). Lastly, updated the highlighting animation--I am really not particularly interested in animation as it tends to slow down the interaction with the patch, so the animation is much shorter and more minimal. Potential value is leaving it as this to provide visibility of the nlet being highlighted when we are already over it with the cursor, which will otherwise occlude the nlet altogether. Another consideration with the currently committed highlight is that it is hollow inside which looks IMO distracting. Curved edges is also distracting since no other aspect of the UI (save for the customized data structures created by the user) is not curved.