focus issues when using docked palettes

[jimmac]

There are some workflow killer issues when using docked palettes. To give an example:

* Create an object, say rectangle
* Bring up the fill and stroke properties, ctrl+shift+f. make sure the palette is docked on the canvas window.
* Change the stroke size to 3 pixels in the last tab.
* Move over to the canvas and push 'n' to get the node editing tool to round the corners. Nothing seems to have happened, you click somewhere on the canvas, you lose the stroke.

What actually happened is you appended 'n' to the stroke size entry and that got evaluated as 0 once you lost entry. There are even more extreme cases when working with the layer palette, as you can start creating objects outside any of the layer groups after some of these focus mishaps.

[bbyak (buliabyak)]

What needs to be done is that to all activate callbacks in all dialogs, a defocus call must be added which passes focus to the canvas of the active desktop after you click any button or press Enter in any spinbox, the dialog is defocused and you can continue working on canvas. Still, this allows you to navigate the dialog by keyboard without losing focus. I did something like that long ago, but not consistently, and it apparently does not work anymore with docked dialogs. Gustav, can you please look into this?

[bbyak (buliabyak)]

Gustav: I'm now doing some heavy work and this problem is really annoying. Can you please weigh in? Can we perhaps find some way to automatically defocus a dialog once any activate callback is fired, so we don't have to manually add such defocusing in a million of places?

[gustav_b (gustav-b)]

Sorry for my lack of action and the annoyance it's causing, I'll
spend some time on it this week.

If the widgets have activates_default set they should signal
their containing window which in turn would emit
an "activate-default" signal. I guess that could be handled to do
the canvas focusing. The only other solution I can think of is
replacing the widgets with our own (subclassed) versions of them
which overrides on_activate, but that would be a lot of work
considering that a mix of gtk and gtkmm widgets are used. Also,
it's probably not what we want anyway.

How did your old solution work? By manually adding signal
handlers to each widget?

[bbyak (buliabyak)]

On Mon, Mar 17, 2008 at 7:37 AM, gustav_b
<email address hidden> wrote:
> How did your old solution work? By manually adding signal
> handlers to each widget?

Yes. I wrote sp_dialog_defocus_on_enter and manually called it for all
spinbuttons (and probably buttons too). It worked but now we have a
lot more dialogs and controls :)

So I was wondering, can we try something more drastic - for example,
forbid a docked dialog from taking focus at all? Ideally this would
still allow the keyboard navigation among widgets in a dialog, but if
not, I'm willling to put up with that (now that we have lost the
Alt+letter shortcuts anyway). I think the unability to tab from widget
to widget in a dialog is a lesser evil than this stocky focus that
forces me to press Esc after I do anything in a dialog. Or at least,
make the "docked dialogs do not take focus" optional.

[philodygmn (mail-address-general)]

Scoping focus to the canvas if the mouse is over it would be a good first step. But I do vouch for the problem's obtrusiveness. I often copy from a scratch layer then hide it, but when I go to zoom out it makes me deal with some random text field in the palette.

[sailor595 (billc595)]

You know what other graphics programs do differently to fix this problem all at once from the top down?

I stopped and checked my other favorite paint program to see how it handled this general focus issue. Gimp captures tab, enter and space in dialogs, same as Inkscape. With the same dangers. Use the crop tool to select an area, but before clicking inside or hitting enter select the resize view widget in the status bar. Enter 33 and like before don't press enter. Hover the mouse over the crop area, press enter => the window resizes to a 33% view. Press enter again => window is cropped. Reverse the order by entering a view % number first then creating the crop box and the first enter crops, the second resizes. And until pressing enter or touching something else with stylus all numbers are grabbed by the view size widget.

They don't do anything differently to fix this problem all at once from the top down.

But they don't have this problem.

Opinion. This isn't as large a meta issue as you assume. People are used to a little focus confusion between the mouse and keyboard in a GUI. I think the problem is poor execution in creating the specific dialogs in question. The specific problems you've mentioned above have been problems for a very long time now. I don't think there is an awesome general fix coming. Only more user frustration with these long standing annoyance bugs.

The box that accepted 'n' in for width zero in the stroke-fill dialog should pass along everything but digits, and it shouldn't come up highlighted and ready for entry right when you select the tab, the user might only be checking the info there, or maybe he opens that dialog every time he starts a new image. The layers dialog is just bad. There is a totally useless function that grabs alphanumeric keys (s is grabbed, ctrl-s goes through and opens a save dialog) without any visual indication that it is going to do so. Similarly the type ahead find in the effects list, such a function in a non-modal box might just not be doable at all, in a main window sure, or after you click in a 'search' or an 'effect name' entry box and a obviously different and important box traps your keyboard sure, but not the way it's implemented (it's not a 'the way you coded it' problem, it's a 'what you tried to do in the first place' problem).

Short term solution: (All that's really necessary)
Just fix the worst offending dialogs. Others should just be changed as problems arise or in the natural course of other fixes and updates. If at all.

*Long term solution: (Who cares?)
This is only a problem in a few very select areas but I've included one at the bottom if you're interested in my long winded rants.

DS

*Long term solution: (To prevent recurrences in other areas.)

Follow proper GUI expected behavior for non-modal dialog boxes and tool bars. No key entry of data until the user clicks or tabs to the entry point (not just the dialog in general) and it is redrawn appropriately to make it obvious (no instant on keyboard focus to some data entry box when the dialog first opens). Only 'tab' (and it's shift and ctrl variants) and 'enter' can be captured immediately o...

[ScislaC (scislac)]

In the external-gdl branch things work more closely to what is desired. If you click into an input field (as the example here), it will just input the letters into the field. However, if you use a slider, or other widgets that don't take input, the keys will switch tools as expected. A side effect of things not changing focus though is that if you click into an input field and then use a slider, the input field is still considered actively clicked into.

[philodygmn (mail-address-general)]

Something's selected on the canvas, I click on unclaimed space in the layers palette (between columns or in blank space where no layers yet exist) when docked, and even though my selection continues to appear active on the canvas, any keystrokes instead are captured by some random text field which springs forth in the layers palette, and loses me my canvas selection, to boot!

When there are enough layers to fill the palette, it doesn't show a text field, then crashes.

[mray (mrayyyy)]

This is an absolute worflow killer. It is a source for crashes and a permanent annoyance to be punished for not remembering to focus manually before using shortcuts. It is also 7 years old now. Can we at least change the importance level?

[mray (mrayyyy)]

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.

Moved to: https://gitlab.com/inkscape/inbox/issues/376
Closed by: https://gitlab.com/mray