1. Christopher Keil Avatar Christopher Keil
  2. Untitled project
  3. TreeView3
  4. Issues

Hovering indicator (red font and red line) moves while clicking on options in export window

Issue #403 resolved
Anastasia Baryshnikova created an issue

USE CASE: WHAT DO YOU WANT TO DO?

Select various options in the export window

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

Open any matrix, click File > Export, click on "All" & watch the column labels. Then move the export window somewhere else on the screen, click "Selection" then "All" again and watch the column labels.

CURRENT BEHAVIOR

Every time you click on "All" the red hovering indicator (red font on the column labels and the red thick line on the tree) move where the cursor have clicked.

EXPECTED BEHAVIOR

Nothing.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

none

FILES AFFECTED (where the changes will be implemented) - developers only

unknown

LEVEL OF EFFORT - developers only

minor

COMMENTS

Comments (26)

  1. Robert Leach

    There's another issue that I can see in the video. The aspect ratio "as seen on screen" is incorrect when you select the area to be the selection. The shape of the dots should not be different in the main window as it is in the preview, but instead the selection is shown as elongated. I have pointed out in the PR that the calculations for the aspect ratio should be using the methods in the ExportHandler class which should effectively fix this issue, but now that I see it has a real effect, I'll create another issue with this particular behavior described.

    Note that if you were to export the selection (as selected in the video), the exported/selected region will look the way it does on the screen with roughly squarish tiles (instead of flat).

  3. Anastasia Baryshnikova reporter

    Yeah, I don't know if it's easy to fix but it would be nice if neither of these 2 behaviors happens. BTW, I like the way the options are spatially organized on your version (in mine they were a bit more squeezed together).

  4. Robert Leach

    The squeezed together ones reflect the requirements in issue #292. They are that way in anticipation of accommodating the more advanced features planned in later versions (also reflected in #292). If there weren't more features planned to put in that interface, I would agree with you. Though I think it would be less disorienting if newly added features later do not change how elements are currently offered. But the strength of that opinion is only 25% - so I don't mind if we make it roomier in the near-term.

    An example of what's planned:

    https://bitbucket.org/repo/AXqk7r/images/351882843-exportdialogmock3.png

  8. Robert Leach

    So it turns out @abarysh, that the fix for this also prevents labels from following the mouse when another app window has focus. For example, if you have TreeView side-by-side with another app (e.g. Safari or Text Edit) and that app has focus, the whizzing labels will not follow the cursor if you hover back over the TreeView app.

    Personally, I like that fact that you don't have to click on TreeView to be able to peruse the labels, especially since clicking the window can deselect any current selections.

  9. Robert Leach

    I spoke too soon. Looks like Faizaan figured out how to get it to work in the context of other apps having focus.

  14. Anastasia Baryshnikova reporter

    I think I noticed this too. You may want to open a new issue on this. ( @hepcat72 -- could you assign the right priority to the issue, once it's created?)

  15. Robert Leach

    I programmed it that way intentionally actually. There are a few reasons. I'm in the airport right now, however I can talk about it tomorrow when I get in. Of course we can suspend the movement of the bolding when any of the settings windows are in focus, but any other time the changing of the display when the cursor is outside of the window needs to happen for 2 features and also was intended to allow people to see where things are 2 windows are beside one another.

  16. Anastasia Baryshnikova reporter

    Can you expand on this? Which 2 features is this needed for? My natural tendency is -- when the window (of any software) is not in focus, it should freeze in the state it was right before I clicked away.

  17. Robert Leach

    Both reasons have to do with dragging. The main reason is the way scrolling works for the labels. And note, the first applies to when the labels are longer than the area in which they're displayed. When your cursor hovers off the app window while dragging the labels' scrollbar, you don't want the app to freeze. You want it to continue updating. When users grab a scrollbar and start scrolling, they expect the interface to update as long as the mouse button is depressed. They might not realize that their cursor has dragged off the window, but it does rather frequently in my experience. Before I implemented the hover update feature the way I did, scrolling the labels was difficult and frustrating because the labels kept disappearing during dragging. The other scenario is when making a selection in the matrix. It had the same issue. If a user wants to select something up against an edge, they tend to click somewhere in the center and drag to (and past) the edge to be sure to get the things on the edge. In those instances, you want not only for the selection rectangle to continue updating, but also the labels so they can be precise in their selection.

    That applies to dragging, but obviously I also allowed updates when hovering only. Initially, I had allowed the labels to update even when the cursor was outside of the app window (but in-line with one of the dimensions) to facilitate easy perusing of labels without worrying where your cursor goes - the same idea behind scrolling the labels by dragging the scrollbar. The scenario in which this matters is when a tree has a thicket of branches near the top and the user is hovering over them either to make a selection or view the associated labels. I didn't want the user to be distracted by where their cursor may stray in the uninvolved dimension. If the updating stopped working, it would be an annoying experience to "scroll" (by whizzing) the labels. We eventually decided to not allow constant updating when the cursor is off the app, but to mitigate the difficulties/annoyances described here, I implemented a timer - when the cursor strays off the app or over a pane boundary, updating continues for a short period and stops there-after.

    There's also a technical reason for the behavior as well. Interface updates used to be initiated by mouse event classes. The number of updates triggered actually turned out to be greater than necessary and the way the Java architecture handles so many triggering events is the arbitrarily merge/skip some events, which made the whizzing label experience choppy and non-fluid. It was drawing way too much and slowing things down too, so to get around this, I disassociated the frequency of the update calls from the mouse hover triggering. Instead, I used the hover to start and stop a series of time-spaced updates in some fraction of seconds-intervals. This meant, I had to grab the cursor position outside of the normal mouse classes and the mechanism of doing that got the cursor position wherever it is on the screen - regardless of pane and regardless of app focus. This also allowed updates between pane hovers to work without having to make the classes explicitly communicate, which simplified the class structure. It also enabled the updating outside of the app window. I personally considered the updates outside the app window upon hover an added bonus, because I tend to work with multiple windows on the screen in all corners of the screen. Maybe that's just me, but I consider it a flexibility feature to be able to control something in the background. That is actually a feature supported by the OS in other areas. Most people probably don't know this, but command-clicking a non-focussed app allows you to click buttons on unfocussed windows without actually bringing that window to the front.

    There may actually be one or two other reasons I did it the way I did that are not occurring to me right now, but suffice it to say, the behavior was intentional. Just remembered - when selecting labels, you want selections to continue even when the cursor strays off the edge too (same reason as the first 2 reasons). That currently isn't implemented for trees, but there's an issue for that.

    I will accede to the possibility that hover updates (not drags) when the app is in the background (or behind a settings window) may be considered as annoying or distracting to some users and doesn't serve a critical enough purpose to justify it in that context. So here's what I propose: since I am familiar with the way it works (which is non-standard), I can create and take an issue to halt updates when the app (or main window) doesn't have focus.

  18. Anastasia Baryshnikova reporter

    Is "off the app when app is in focus" and "app out of focus" the same thing? I think your reasons are great when "off the app when app is in focus". But "app out of focus" means you've clicked on another window and are no longer doing anything in Treeview.

  19. Robert Leach

    I was just playing around with this. There appears to be a distinction here I didn't see before. I thought this was in general about app focus, but I see that there are multiple behaviors depending on context:

    1. When a settings dialog is present in whizzing mode (i.e. more data is displayed than there is amount of space for a label per row/col), there are 2 things that can happen (depending on how the settings dialog is brought up). Either the labels disappear and never come back until the settings dialog goes away regardless of app focus (which is the same as how the app behaves with a cluster or export dialog) OR:
    2. the whizzing labels freeze in place and are no longer associated with cursor position and will whiz again when focus changes to another app. This means that in effect, the labels displayed and frozen in place no longer have any visual connection with the data displayed.
    3. In every other context (switching apps regardless of whether there are no other treeview windows in front of the main treeview window or not - i.e. clustering window or export window), when the cursor hovers over another app's window, the labels disappear. Even if another app has focus - if you hover over the backgrounded treeview app (main, cluster, or export windows - not settings), the label whizzing resumes.

    (Number 1 can be initiated by right-clicking the labels, highlighting the settings option, click and hold, hover back onto the labels, release the mouse button, then hit your return key.)

    I think that a more consistent and "safer" behavior (to a degree) would be to always make the labels disappear when the user hovers over either a dialog or another app window as opposed to freezing the labels in place because it does not leave un-data-linked labels on the screen, available for the user to inappropriately make a visual association. I'd argue that the behavior of resuming whizzing when over the main treeview window (only) in any context is desirable.

    Here are the arguments I would make for this: 1. When changing the label settings, being able to hover over the matrix without dismissing the label settings window allows users to see the effects of their changes. 2. when app focus changes, if a user uses multiple windows on a desktop at a time (like me), they will not have to switch apps to consult/view labels while, for example, entering text. They could hover the cursor and leave it in place over a label of interest while composing text about a specific region/collection of labels. So I would also propose that whizzing labels should disappear when the cursor hovers over a treeview dialog or other app window and resume whizzing any time the cursor is over actual labels or data regardless of the "fore-groundedness" of the main window.

  20. Robert Leach

    Is "off the app when app is in focus" and "app out of focus" the same thing?

    The original whizzing code makes no distinction based on app focus. The code added to stop updates when the settings window is present freezes the label updates instead of making them disappear and the freeze is only when a settings dialog is present and the app is in focus. I think that instead of freezing, the labels should disappear and I think that whizzing labels should reappear if the only thing under the cursor is the main treeview window regardless of app focus, but I'll admit that's mostly my own personal preference. The only context I can support that behavior with a direct reason is when changing label settings.

  27. Log in to comment
Assignee
Type
bug
Priority
minor
Status
resolved
Component
Import/export
Milestone
F/S - 01
Version
beta2
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!