Re: [hatari-devel] SDL GUI keyboard shortcuts

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 14 elokuu 2014, Thomas Huth wrote:
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
....
> I also mixed up Enter and Space when I tried to control the GUI
> with the keyboard, so I think there is really something that has
> to change here.
> What about always activating the focused item with Enter (or Space),
> and just putting the focus on the default button at the beginning?
> Then behaviour is the same for people who do not use the cursor
> keys (Enter activates the default button). And for people who use
> the cursor keys, they certainly do not expect the default button to
> be handled with Enter anymore.

Done. I added support for Home & End keys to move to first
and last item so getting back is be done now either with Enter,
or if focus was moved, with End+Enter.


> > > 3) The blue color for the focus is ... hmm, maybe ok ... but
> > > wouldn't it fit better to use a lighter shade of grey instead, for
> > > example?
> > 
> > I'm not attached to that color (it's just a place holder),
> > but IMHO the current gray scheme is a bit bland.
> > 
> > I started to move specifying of the SDL GUI colors into
> > same place, in preparation for potential later themeing
> > for the colors.  I was thinking that if it were configurable
> > from a text file, people could experiment with different
> > color combinations and we could before release pick nice one
> > as default + ship few good ones with Hatari.
> > 
> > Would you be interested / have time to look into that?
> 
> No, since I personally don't need theming support in Hatari.

Feel free to change the current colors.focus in sdlgui.c to
whatever color you think best.

Btw: underline is also non-gray.  Before changing it, make
sure that the underlines in new color are visible enough in
non-zoomed GUI ("./hatari -z 1" + F12).


> > And maybe add joystick support to GUI keyboard navigation?
> > :-)
> 
> I currently do not got my joystick with me (I'm away from home),
> so currently I also can not look at this.

Ok, I might look into that later.


> > As a result, at some point const string contents need to be set
> > to non-const struct member when specifying button/text string.
> > Doing it in the current place gives the least amount of warnings.
> 
> Hmm, sure, but this has never been a big issue in the past. For example,
> I wonder why the recent GCC then does not complain at the other
> places, like in dlgScreen.c:
> 
>  windowdlg[DLGSCRN_RECANIM].txt = "Stop record";

Because those GCC warnings are explicitly disabled in SDL GUI
CMakeLists.txt with "-Wno-write-strings" (I couldn't find
better way to deal with them).

That option doesn't disable warnings for const -> non-const
char* assignments though, only for literal string assignments.


> > Other alternative would be to dup the string & free it at every
> > function exit, but doing it just to silence a warning seems
> > icky.  Strings for non-editfields aren't modified.
> 
> That sounds ugly. A proper solution would maybe be to use a union for
> the txt field instead, something like:
> 
> typedef struct
> {
>   int type;             /* What type of object */
>   int flags;            /* Object flags */
>   int state;            /* Object state */
>   int x, y;             /* The offset to the upper left corner */
>   int w, h;             /* Width and height (for scrollbar : height and
> position) */ union {
>     char *txt;          /* Editable text string */
>     const char *ctxt;   /* Constant text string */
>   };
> }  SGOBJ;
> 
> What do you think about that?

I have a dim recollection that I would have tried that.

As union members refer to the same memory object, it's
not really different from cast.  You will be assiging
const object to something that is stated to be modifiable.


> > Any comments on what to do about the file selector?
> > 
> > GUI has no concept of lists or their focus, so adding
> > that just for file selector would be a lot of work.
> 
> I think adding some special handling there is still the best thing
> that we could do. After all, the fileselector code is already
> handling SDL event to implement some special actions like
> page-up/down and mouse wheel support.

I'm not myself interested in adding support for that.
Feel free to implement it! :-)


> > Other alternative I was thinking was adding file name
> > completion.  When user types first letters for a filename,
> > GUI will:
> > - put to edit line the first file name matching
> >   the typed letters so far
> > - move the list so that this file name and ones
> >   following it are visible (which could be selected
> >   by typing more letters)
> > 
> > To type another name, user needs to pause typing for
> > a while.
> > 
> > Matching should IMHO be case insensitive, so the list
> > sorting should be made case insensitive too.
> 
> I don't think this is the right way to go since
> a) This is likely also quite a lot of work
> b) Sounds somewhat non-intuitive to me, so I guess you
>    either end up explaining this feature again and again
>    or hardly any user will use it

It's a common feature in file selectors and especially
file managers (on Windows, Linux, Atari...).

You open file manager, type few letters from start of
a filename, check that expected file got selected,
press enter and it opens.

> c) This als only works if the user really has a keyboard in front.
>    For controlling the GUI with a joystick, this simply does not work.

True.

I don't think it to be more work than adding focus support
for selecting the file name, but it will definitely be
quite a bit of work, so I can definitely skip this. :)


	- Eero