Discussion:
Keyboard navigation... (F6, F8, ...)
(too old to reply)
Jon A. Cruz
2006-01-23 09:45:16 UTC
Permalink
We seem to have a bit of a problem now.

It turns out that the reason F6 and F8 became 'broken', is that they
are reserved by GTK for stock navigation when a splitter pane is
involved in the UI.

It turns out that F6 is used to switch between current panes, and F8
to switch to the splitter itself to allow for keyboard resizing.



I don't think we can just arbitrarily remap those, since it's part of
the accessibility project and was designed to coincide with the use
of keys on other platforms/toolkits.

So I think we're now faced with the decision to either not allow any
GtkPaned widgets in our UI, or to give up F6 and F8.



As a follow-up item, we probably need to do something I've been
thinking of for a while and list out the different keys and how
they're used on different platforms and in different applications.
One thing tweaking things a bit for me is that on OS X, F9-F12 are
used for basic OS-wide features, and other can be also (especially on
laptops).
http://guides.macrumors.com/Keyboard_shortcuts
(the three links at the bottom of the page are quite helpful)
Joshua A. Andler
2006-01-23 14:59:45 UTC
Permalink
Post by Jon A. Cruz
We seem to have a bit of a problem now.
It turns out that the reason F6 and F8 became 'broken', is that they
are reserved by GTK for stock navigation when a splitter pane is
involved in the UI.
It turns out that F6 is used to switch between current panes, and F8
to switch to the splitter itself to allow for keyboard resizing.
Is this paned view done to make the swatches resizable vertically? I was
under the impression that the panels you spoke of would effectively be
like toolbars/dialogs/whatever you want... basically a customizable
widget holder that would resize as well as float or lock-in to the UI,
am I mistaken?
Post by Jon A. Cruz
I don't think we can just arbitrarily remap those, since it's part of
the accessibility project and was designed to coincide with the use of
keys on other platforms/toolkits.
So I think we're now faced with the decision to either not allow any
GtkPaned widgets in our UI, or to give up F6 and F8.
I could see a side-by-side paned view being useful for some things, such
as a split view ports, the xml editor (since dialogs don't stay on top
in gnome on fullscreen or win32 at all), or for the list view of
swatches. But the regular swatch view (no text) makes less sense to me
for a paned view.

And I'm definitely not questioning your methods, I just don't really
understand it and am looking to get a better grasp on things.

-Josh
Jon A. Cruz
2006-01-23 17:28:54 UTC
Permalink
Post by Joshua A. Andler
Is this paned view done to make the swatches resizable vertically?
I was under the impression that the panels you spoke of would
effectively be like toolbars/dialogs/whatever you want... basically
a customizable widget holder that would resize as well as float or
lock-in to the UI, am I mistaken?
There was a request to make the swatches/panel area resize by
dragging the top border. The standard way to do that in GTK+ is to
use a GtkPaned splitter (either GtkHPaned or GtkVPaned).

If we want standard functionality we should use standard widgets (one
of the big problems that bit Sodipodi). If we don't require that
functionality, however, then we don't need to use those widgets. I
don't really have a preference to use it or not. Just as long as an
informed decision is made I don't care so much which way it is decided.



However... there is the long-term issue that we need to try to keep
keyboard navigability in some manner. Ideally one could operate any
given program without having to touch a mouse. This isn't just an
issue for those without mice, but actually comes in to all sorts of
assistive technologies, where sometimes things are just helping given
users instead of replacing mouse use altogether. And for such usage,
keeping with standard keys keeps the user from being surprised and/or
annoyed.

The Freedesktop effort just getting underway to address this issue in
general is at
http://www.freedesktop.org/wiki/Standards_2fdefault_2dkeys_2dspec

And the GNOME details are at
http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html
bulia byak
2006-01-23 17:41:58 UTC
Permalink
Post by Jon A. Cruz
However... there is the long-term issue that we need to try to keep
keyboard navigability in some manner. Ideally one could operate any
given program without having to touch a mouse. This isn't just an
issue for those without mice, but actually comes in to all sorts of
assistive technologies, where sometimes things are just helping given
users instead of replacing mouse use altogether. And for such usage,
keeping with standard keys keeps the user from being surprised and/or
annoyed.
Sure, except that standard keys for panes are NOT applicable here.
This is not a pane, from user viewpoint. It's not more of a pane than
the statusbar. So the pane keys must be disabled.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Jon A. Cruz
2006-01-26 07:06:02 UTC
Permalink
Post by bulia byak
Sure, except that standard keys for panes are NOT applicable here.
This is not a pane, from user viewpoint. It's not more of a pane than
the statusbar. So the pane keys must be disabled.
Perhaps... or perhaps they might be the more appropriate.
But that's less of a concern.


Following up on what I'd mentioned earlier, the main question is
whether or not we'll want to have any GtkPaned widgets in our main UI
at all.

(I was going to get this up before, but it took a little tweaking of
the wiki...)

I did a quick mock up of something that's been discussed on and off,
and does seem like a reasonable option to me
http://wiki.inkscape.org/wiki/index.php/SplitPaneUI

Just one thing to consider.
Alexandre Prokoudine
2006-01-26 08:42:26 UTC
Permalink
Post by Jon A. Cruz
I did a quick mock up of something that's been discussed on and off,
and does seem like a reasonable option to me
http://wiki.inkscape.org/wiki/index.php/SplitPaneUI
Will this part of settings be saved for each document separately?

Alexandre
bulia byak
2006-01-26 16:19:31 UTC
Permalink
Post by Jon A. Cruz
I did a quick mock up of something that's been discussed on and off,
and does seem like a reasonable option to me
http://wiki.inkscape.org/wiki/index.php/SplitPaneUI
Personally, I don't like this kind of interface. Looks clunky to me.
Your screenshot in particular reminds me (painfully) of the DOS
application called Paintbrush, back in the late 80s. It didn't have a
zoom tool, instead when you wanted to zoom, it split the window into
two panes, one showing 2x zoomed version of the other. This was
atrocious.

That said, If enough people want this, I would not object to you
implementing it, _so long as_ F6/F8 keep working for tools when there
are no panels.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Jon A. Cruz
2006-01-26 17:58:01 UTC
Permalink
Post by bulia byak
Personally, I don't like this kind of interface. Looks clunky to me.
Your screenshot in particular reminds me (painfully) of the DOS
application called Paintbrush, back in the late 80s. It didn't have a
zoom tool, instead when you wanted to zoom, it split the window into
two panes, one showing 2x zoomed version of the other. This was
atrocious.
Well... it depends a lot on the program and how it's been implemented.

http://www.cs.wisc.edu/graphics/Courses/cs-838-1999/Students/soumya/
assignment1/Image3.jpg
Loading Image...

3ds max, MS Word, Maya, Blender, MS Excell, Gnumeric, etc. all do it

Much depends on the subject, the workflow and the individual doing
it. The latter is probably one of the biggest issues.
Post by bulia byak
That said, If enough people want this, I would not object to you
implementing it, _so long as_ F6/F8 keep working for tools when there
are no panels.
Seems reasonable.

And we don't even need a "bulia.happy" preference to do that. Just
keep it one of the standard workflow use cases. I'm thinking that we
probably need to list out some of those more explicitly.
Joshua A. Andler
2006-01-26 18:19:03 UTC
Permalink
Post by Jon A. Cruz
Post by bulia byak
Personally, I don't like this kind of interface. Looks clunky to me.
Your screenshot in particular reminds me (painfully) of the DOS
application called Paintbrush, back in the late 80s. It didn't have a
zoom tool, instead when you wanted to zoom, it split the window into
two panes, one showing 2x zoomed version of the other. This was
atrocious.
Well... it depends a lot on the program and how it's been implemented.
Loading Image...
http://www.softpedia.com/screenshots/3D-Studio-Max_2.png
3ds max, MS Word, Maya, Blender, MS Excell, Gnumeric, etc. all do it
Much depends on the subject, the workflow and the individual doing it.
The latter is probably one of the biggest issues.
I know this split pane for the canvas would be handy for a few of my own
projects. My Q is, will this make rendering speed any more painful or
would it basically render the same speed as a single canvas?
Additionally, if we could even do it so the additional panes could have
either normal/outline views toggled individually that would super rock
(my old 3D mentality showing through with that one).

-Josh
MenTaLguY
2006-01-28 00:26:33 UTC
Permalink
Post by Joshua A. Andler
I know this split pane for the canvas would be handy for a few of my own
projects. My Q is, will this make rendering speed any more painful or
would it basically render the same speed as a single canvas?
It would probably be slower than a single canvas, but not twice as slow.

-mental

Ralf Stephan
2006-01-23 10:20:45 UTC
Permalink
Post by Jon A. Cruz
As a follow-up item, we probably need to do something I've been
thinking of for a while and list out the different keys and how
they're used on different platforms and in different applications.
One thing tweaking things a bit for me is that on OS X, F9-F12 are
used for basic OS-wide features, and other can be also (especially
on laptops).
And there are laptop keyboards (like mine) that don't have
F11 and F12.


ralf
bulia byak
2006-01-23 16:42:15 UTC
Permalink
Post by Jon A. Cruz
So I think we're now faced with the decision to either not allow any
GtkPaned widgets in our UI, or to give up F6 and F8.
The color swatches are not significantly different from other parts of
the UI. They are not a separate document pane, and they don't need
focus. The only difference is that they are resizeable, but I don't
think that resizing deserves a key of its own. So, either we shouldn't
use this widget, or (preferably) disallow it to grab these keys,
because the accessibility reasoning does not apply here. In any event,
certainly giving up the keys for the UI is not an option.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
Loading...