About new palette editor in Anatomist

[sapetnioc]

I started to use the new palette editor as is I were a neophyte user knowing very few things about Anatomist. I start this discussion to give some feedback.

[sapetnioc]

Clicking on these icons always open a new window

The link with the original palette editor can be quickly lost when other windows are in front. It would make sense to have only one instance of each window (one for each icon) and that clicking on the icon either create a non existing instance or raise the existing window in front of others.

[denisri]

This is not really a problem on the long run: this icon is only here temporarily for testing purposes so that you and others can try the palette widget. Next, it will either totally disappear, or be integrated in the regular palette widget, replacing the palette view + existing sliders.

[sapetnioc]

Windows that pops up without any border and capture the keyboard and mouse events are not intuitive. For instance if I click on the palette, it creates a similar borderless window with sliders but when this window is opened, I cannot click on another software window or even use ctrl+tab to switch to another software. It is mandatory to first click outside the borderless window to close it.

This is the same for the palette selection window. It is not obvious that it is necessary to click on "Close" button or outside the window to close it.

I have the feeling that there must be only one window (i.e. top level widget) with a changing content. This would let the desktop manager do its job to manage interactions between all windows. On the other hand, this approach makes it impossible to just click outside the window to go back to its previous state (i.e. hide or close the widget corresponding to the borderless windows). I don't know what alternative could be non-intrusive for the desktop manager, intuitive and ergonomic.

[sapetnioc]

I thought about loosing the focus to replace clicking outside the borderless window but I believe this is not a good idea. One often loose focus to temporarily switch to another window (in Anatomist or another software) and going back to the palette window should not change what was going on.

[sapetnioc]

In the palette selection sub-window, a double click could close the sub-window.

[denisri]

Thanks for the feedback. I was asking for comments, precisely because I had the same doubts about the ergonomy of the "double window" thing.

Using the "focus out" to determine when to close the edition window was what I had done at first, but as I am personally using a "focus follows mouse" setting in my desktop, just moving the mouse accidentally a bit outside of the slider was closing the sliders, which was very annoying. So I had to change.

The double-click idea for palette selection is good.

Using a single window/widget with changing contents would be an alternative in some contexts, but not in all: as the changing contents will require more space than the original palette view (when adding sliders), the layout outside the widget, when used inside a parent window, will change the layout, potentially moving lots of things around, and will likely not go back to its original size when hiding the sliders. This is the reason why I used this additional popup window. But I wasn't sure it was a good idea, and it appears that it is actually not :)

What I wanted at the first place was a palette widget which is as small as possible in order to use many of them in a table or list of contrasts with each a different palette. As we need to edit only one at a time, at most one sliders pair needs to be visible at a time, and I also wanted the contrasts table layout not to be messed up when editing a palette. So I had this popup window idea, and I don't have a better one for now...

[sapetnioc]

I think the idea is good. We can try to find a way to make it more compatible with desktop manager. For me these "double windows" are sub-windows and there can be several of them (e.g. one for the sliders and another one for the palette selection). I see them as window modal QDialog of the widget that created them. One cannot do anything on the widget without closing the dialog first. But the dialog must not prevent to do anything on other widgets/windows. Are these windows QDialog ? If not, could a QDialog fix the interaction with other windows (putting aside the problem of not being able to close the dialog by clicking next to it) ?

[denisri]

I've been trying using a modal or window-modal dialog, but unless it is set in popup mode (the current implementation, which prevents the ctrl-tab switching), it doesn't loses focus nor receives click events outside its rectangle, so basically never closes (unless hitting since the latest push a few minutes ago). Maybe the events can be received from the parent, I will go on looking...

[denisri]

No: when the widget is modal and not a popup, I can't get clicks outside of the window and close it when needed. And when in popup mode, it makes no difference being a regular QWidget or a modal QDialog.