Re: [hatari-devel] SDL GUI keyboard shortcuts

[Thomas Huth <th.huth@xxxxxx>]

Am Thu, 14 Aug 2014 23:17:04 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> > > 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).

D'oh, I already forgot about that one.

> > > 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.

It indeed did not work for the SGOBJ struct, but I was able to add a
similar hack to the place where the warning occurs, so I silenced it
there instead.

> > > 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! :-)

I've added now basic cursor support for the file selection, too. It's
still quite cumbersome, but I think it's better than nothing.

> > > 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.

Sorry, I was not quite clear here, when I said non-intuitive, I meant
that "user needs to pause typing" stuff. I guess that would cause quite
some confusion.

 Thomas