Feature request: click and drag signals (adding multiple signals is unintuitive)

[slagernate]

It can be quite unintuitive how to add multiple signals. The best way by far (to my knowledge) is to shift select and hit the "append" button --however, as simple as this sounds, I didn't realize this was possible for the first few months I was using gtkwave (only after seeing it on a youtube video); and I'm not the only one who didnt' realize this -.-

If we can click and drag a single signal, why not allow for multiple signals?

[tbybell]

You can definitely do multiple signals. Let's say you're doing it with the ctrl clicking to select a spread out number of individual ones. left mouse click on signal A control left mouse click on B control left mouse click on C but do NOT release the left mouse button. drag from SST dir/type/signal window over to the signal or waves pane. release left mouse button.

When you want to start a new group to drag and drop import, click on the first signal in the dir/type/signal without control. Start/end regions of adjacent signals with shift click work also.

[slagernate]

I see. I didn't realize we had to hold down the ctrl / shift key all the way til we finish dragging and dropping. This was quite unintuitive for me and others I know. I think new users would greatly benefit if dragging and dropping worked like most common filesystems' UIs.

[tbybell]

I should have been more specific. You can actually release ctrl/shift key before you start the drag. You can't release the mouse after the last click though because the semantics of clicking will deselect everything that was already selected if a mouse click is encountered that isn't also qualified with shift or ctrl.

[slagernate]

Again, I didn't realize this, and I guarantee most users won't either. Linux, Mac and Windows and most other UIs all behave differently.

[tbybell]

I believe those are the standard GTK semantics for selecting items from a list. They definitely were going quite a while back.

In the signal window, I had other semantics earlier similar to what Verdi/nWave and Lotus Notes do to select items without requiring control or shift and users complained that it wasn't compliant with GTK-expected behavior. In previous versions to control the signal window, there was this environment variable:

       use_standard_clicking <value>
              This option no longer has any effect in gtkwave: normal GTK click semantics are used in the signalwindow.

It was removed to support usual GTK semantics. Updates in this area go back to 2008 (version 3.1.3). Users remarking about click behavior is nothing new.

Note that for some widgets such as filechoosers, I've seen where if you drag the mouse after the initial click it will highlight more entries, but the question comes up how you disambiguate this from a drag and drop? That whole Lotus Notes style of simply clicking to invert highlight for an entry has been met with resistance. I like it better, but the user interface compliance police don't. :-)

It's definitely a pain how OSs behave differently.

[slagernate]

IMO tradition shouldn't impede proper design (in this case, a UI that a majority of people are accustomed to). One step back and two steps forward > no steps at all. Just my 2 cents tho. Cheers.

[rfuest]

I had no idea that dragging multiple signals from the SST was possible, so I guess that this is a hard to discover feature.

For GTKWave 4 I want to try to get the default behavior closer to how users expect a UI to work nowadays. I think this is important to make it easier for new user or users that only infrequently use GTKWave. I don't want to make things worse for long time GTKWave uses, who have built their muscle memory over decades, but I believe that these users would prefer to stick with GTKWave LTS anyway.

The development version of GTKWave has some changed drag and drop behavior for reordering traces, but not for adding new ones from the SST. There are still some issues with it, that will be fixed as part of the GTK 4 port. The current code contains a lot of custom implementations of features that GTK also provides that make GTKWave behave differently, because these features weren't available or didn't work as expected in older GTK versions. For the GTK 4 port I'm trying to rely on the default GTK behaviors as much as possible to at least keep it consistent with other GTK applications.

[slagernate]

Yeah, it's quite hard to figure out. Basically broken.

[tbybell]

This sets the widget's selection behavior:

gtk_tree_selection_set_mode (GLOBALS->sig_selection_treesearch_gtk2_c_1, GTK_SELECTION_MULTIPLE);

https://docs.gtk.org/gtk3/enum.SelectionMode.html https://docs.gtk.org/gtk4/enum.SelectionMode.html

No change between the major versions of GTK.

For GTK_SELECTION_MULTIPLE: Any number of elements may be selected. The Ctrl key may be used to enlarge the selection, and Shift key to select between the focus and the child pointed to. Some widgets may also allow Click-drag to select a range of elements.

The click-drag select behavior you want might exist in another widget. I don't know. The big problem is, as I stated before, how does the widget differentiate between click-drag for selecting a range versus click drag to emit a drag_begin signal? You'd still have to add another qualifier (shift flavored key, use a different mouse button, etc., which won't be "intuitive") and you won't get the behavior you want. If you instrument the DNDBeginCB() function, "I'm selecting and the instant I drag off the widget's bounding box is an immediate drag_begin" is not how GTK works. As soon as some number of pixels of click drag occur independent of pointer location relative to any bounding box edge, the toolkit transitions the widget into a DND state.

Like it or hate it, unless you roll your own widgets, in some cases you are bound to the limitations of the underlying toolkit. The funny part is the instant you do write your own custom widget, someone complains that you didn't use the stock widgets and wrecked some aspect of theming such as text rendering at 45 degree angles. :-)

Note that if you click on filenames (shown as a text list) in File Explorer in Windows, it looks to me like the same behavior as the signal names for the SST, right on down to shift/ctrl for multiple items versus DND. Are you on Mac or something and it does things differently? (It's been a while since I've touched OSX.)

[rfuest]

I don't think that the disambiguation of click dragging to select multiple items and starting a drag and drop operation is the problem. Using shift or control to select multiple items is a common UI pattern on desktop and not something that is hard to discover. GTK 3 does even support rubber band selections in tree views (https://docs.gtk.org/gtk3/method.TreeView.set_rubber_banding.html), but I don't think this works reliable enough to be useful in our use case.

The main issue is that pressing down the mouse button already changes the selection to the signal under the cursor, which prevents the user from dragging multiple signals at once. By delaying the selection change until the mouse button is released it is possible to detect a drag and drop operation. If the cursor has moved for a certain distance (https://docs.gtk.org/gtk3/method.Widget.drag_check_threshold.html) it is a drag operation, otherwise its a selection change. You can compare the two behaviours by trying to reorder a group of selected traces in the waveform view, where the development version uses the described behaviour.

Like it or hate it, unless you roll your own widgets, in some cases you are bound to the limitations of the underlying toolkit. The funny part is the instant you do write your own custom widget, someone complains that you didn't use the stock widgets and wrecked some aspect of theming such as text rendering at 45 degree angles. :-)

I'm not sure if it is possible to configure the GtkTreeView in GTK 3 to support the "correct" selection behaviour. In GTK 4 this widget has been deprecated and the new GtkColumnView is not only much nicer to work with, but also seems to support this selection mechanism by default.

[tbybell]

The main issue is that pressing down the mouse button already changes the selection to the signal under the cursor, which prevents the user from dragging multiple signals at once. By delaying the selection change until the mouse button is released it is possible to detect a drag and drop operation. If the cursor has moved for a certain distance (https://docs.gtk.org/gtk3/method.Widget.drag_check_threshold.html) it is a drag operation, otherwise its a selection change. You can compare the two behaviours by trying to reorder a group of selected traces in the waveform view, where the development version uses the described behaviour.

Thanks. That select on release is key part I was missing. Right, I don't know if GTK 3 can support that behavior. I'll poke around to see if it's possible as I'm curious.