* Label font is not any more erroneously affected by the resizing of the numbox

* The width is now more conservative and accurate

* When a new number was entered that exceeds the numbox width and was replaced by a + or a - and after it was refocused again with a shift pressed (thus entering the append mode), the + did not revert back to the entered number. Now it does (even though you only see the last n digits that fit the numbox--LATER: we may want to add a < or > at the beginning, letting the user know that there are more digits to the left. This however, with the current setup may not be as trivial as it seems, so we will keep it as-is for the time being until users report problems/dislike with the current mode of operation which is still way better than it used to be).

Following a discussion with Ico, make sure to apply the fix to actual
canvas class objects only, so that we do not exit temporary run mode
unless the user really clicked on a subpatch (or abstraction) object.

Fixes a residual regression with MR !528 (Findbox fixes) reported by
Joseph Gastelais, which causes temporary run mode to stick when opening
a subpatch using Alt-click (i.e., mouse click on the subpatch in
temporary run mode). Resolved using Jonathan's fake keyup trick.

If the declare object detects an unrecognized argument which isn't an
option symbol, it will print a weird-looking message complaining about
an empty flag. This commit makes it print a proper warning about an
unrecognized float argument instead.

'aggraef/purr-data-abstractionsaving-final-fix'

Ivica Bukvic authored 4 years ago and Albert Gräf committed 4 years ago

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

Ivica Bukvic authored 4 years ago and Albert Gräf committed 4 years ago

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

Ivica Bukvic authored 4 years ago and Albert Gräf committed 4 years ago

* This means an object has requested exclusive focus

This is broken right now in Testing and Unstable, the fix should still
work in Debian Stretch, Ubuntu Xenial and later.

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.

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

Ivica Bukvic authored 4 years ago and Albert Gräf committed 4 years ago

* Ability to edit incrementally with text and mouse (e.g. backspace erases only one digit)

* Better use of hte '>' as a cursor

* Key presses start a new number from scratch unless user has dragged a number and established a new number by dragging, or unless they shift+clicked when they gained focus on the numbox, in which case numbox will allow for user to append to the existing value

* Shift + backspace erases everything, while backspace erases only one character

* When there are no digits entered, the value reverts to 0

* Pressing return/enter removes the trailing '>' until a key is once again pressed

* Changing values with mouse also removes the trailing '>'

* Resizing across only x and y axes now works (vertical resize still inevitably affects the width due to change in character length, but it now never exceeds the x value it started with during that particular click'n'drag action)

Ivica Bukvic authored 4 years ago and Albert Gräf committed 4 years ago

* drawstyle ported from 1.x (formerly known as hide_frame option

* font sizing applies only to the label, not the number value

* number value is automatically sized based on the numbox height

* improved dialog to accommodate the new option

tar_em_up.sh: Allow the path and name of the dpkg-deb tool to be configured via the dpkg environment variable.

This uses findAndReplaceDOMText(), which apparently looks for
case-sensitive matches, but the search text entered by the user is
*always* converted to lowercase. This means that mixed case search terms
just won't be found, which is bad. (E.g., try searching for "GEM" in the
toc to see this bug in action.)

Fixed by just removing the call to toLowerCase() on the search text,
case-sensitive searches now work as expected, problem solved.

This resolves a long-standing bug (the relevant code is 4-5 years old).
While it is just one little missing check in the keyboard event handler,
which is surely just an oversight, this has the dire consequence of
breaking navigation with the Tab key.

- The root cause for this issue is in the document.body event listener
  callback, where we always reset the focus to the search text input if
  there's *any* keyboard input (other than a LF or CR on the file
  browser and bookmark buttons) while the focus is on something
  else (such as an item in the toc or in the search results). The
  intention there surely was to enable the user to just start
  typing *anywhere* in the dialog, which is convenient, but has the
  unwanted side-effect of breaking Tab navigation (as well as the cursor
  keys).

- The fix is simply to *not* reset the focus if the key event is the Tab
  key. Besides Tab, we also treat the modifier and cursor keys in the
  same fashion, so that these will be handled on the spot rather than
  being forwarded to the search text input. By these means, you can
  still start typing your search terms from anywhere in the dialog, but
  navigation with Tab and Shift+Tab and the cursor keys now also work as
  expected.

- Also, why is the div holding the toc items created again and again for
  each item in display_toc()? I moved the corresponding statement,
  div = document.createElement("div"), right before the toc.forEach()
  loop now, which I think is where it really belongs.

This reverts commit 12bd57bd, reversing
changes made to e9d38d23.

Disable the bookmark icon in situations where bookmarking isn't possible (search results, doc directory).

- Use canonical paths just about everywhere in the help browser. We want
  to stick to portable, normalized paths as much as possible, to avoid
  funky Windows path names, especially in bookmark files which should be
  portable across different platforms.

- Fix the generated click_toc() call in display_toc(); we need to
  properly stringify the callback argument there.

- Update the search field after opening a directory via the file
  browser, so that the search text matches the directory display. Is
  there a reason that we're not already doing this? I don't think so,
  because we're doing the same when clicking a link in the toc.

- Prevent the doc directory from being bookmarked. There's nothing
  interesting to see there anyway (just subdirectories, no help
  patches). Also, since the toc lives there (in a virtual sense, i.e.,
  the current browser directory is set to this directory whenever the
  toc is displayed), we also avoid an interesting race condition which
  arises if we try to update the toc while we're displaying it. (This
  doesn't seem to happen on all platforms, but I've seen it on the Mac
  at least.)

- Fix a purely cosmetic issue with the bookmark entries. (Entries with a
  null description were stored as is and then written to the bookmarks
  file. Now the description is just omitted in that case.)

This takes the form of a little bookmark icon to the right of the file
browser icon. Just the plain icon indicates that the current directory
hasn't been bookmarked yet, and that clicking on it will bookmark it.
If you do this, a little red cross appears on the icon, which reminds
you that the directory has been bookmarked, and that clicking on the
icon will remove the bookmark again.

Note that in general a directory may have been bookmarked multiple
times, by using the keyboard shortcut (Ctrl-D). In this case the red
cross will stick until the last instance of the bookmark has been
removed.

The icons come from the Manjaro KDE Breath theme (a variation of the
KDE Breeze theme), and we also replaced the folder icon with a matching
icon from the same theme. Thanks are due to the Manjaro and KDE teams!

While we were at it, we also fixed the vertical alignment of the icons
with respect to the search field, they are properly aligned to the
middle now.