Re: [XForms] New prerelease xforms-1.0.94pre16

[Michal Szymanski]

Hi,

I could not give the new version any heavy testing, it seems to work
fine in my apps.

As for (a), I did not notice any wrong behavior of Home/End in the
previous versions.

For (c), I think it may be arguable to keep (or to stop) tooltips from
showing on deactivated objects. It is usually info on what given
object is for. As such, it may be a valueble info even if at the given
moment it is deactivated. But it is no big deal, I guess.

I have a few requests for change/fix:

1. File browser. I use it extensively, e.g. in astronomical image
displaying app. When one invokes it once again to open another file,
the list is placed so that the previously selected file is at the very
bottom of the list sub-window. This means that going to the "next
file" requires extra click on the slider. If you go through dozens of
files, it becomes a bit annoying. So the request would be to position
the "last file" somewhere in the middle of the subwindow.

2. Fdesign. Some time ago, after a short discussion, we agreed that it
may be desirable to start the application with NO radio button (in any
given radio group) selected. If one, however, activates "test form" in
fdesign and click any of this radio buttons, it gets selected not only
in the test window but also in the form definition ("value = 1" line
added for the button in FD file). No way to deactivate it other than
manually deleting the line from the FD file.

3. Fdesign. This may be harder to fix, so maybe for some future
release. Once any object properties window is opened, "fdesign" sets
the "changed" flag, even if one does not change anything, just
reviewing the properties. Surely one can "discard" the "changes" on
exit but it is a bit misleading if one has a complicated setup and,
after a while, is not 100% sure whether anything WAS actually changed
or not. On the other hand, "saving" a version which is identical to
the previous one, can also be misleading.

regards, Michal.

On Wed, Jan 02, 2013 at 10:58:56PM +0100, Jens Thoms Toerring wrote:
> Hi,
> 
>    this time its a new pre-release
> 
> http://download.savannah.gnu.org/releases/xforms/xforms-1.0.94pre16.tar.gz
> 
> not because of some stupid error of mine but due to a few
> bug fixes and a new function, all due to Serge Bromow, who
> spend a lot of time doing tests and gave me some code to
> integrate.
> 
> First the bugs:
> 
>  a) Using the <End> and <Home> keys in (single-line) input
>     objects didn't work correctly.
>  b) A deactivated FL_HOLD_NROSWER still reacted to keyboard
>     events (but not to mouse events), now it doesn't react
>     to anything (at least that's what it's supposed to do;-)
>  c) Tooltips were shown for deactivated objects, which didn't
>     make too much sense.
>  d) When converting lots of files with fdesign, using e.g.
>     fdesign -convert *.fd
>     on a directory with many .fd files, at some point the
>     resulting ,c and .h files weren't correct (if there were
>     a total of more than 1024 objects that had ames or call-
>     backs).
>  e) fdesign didn't treat the style setting for labels in-
>     correctly.
> 
> And then there's a new function
> 
>   int fl_set_input_mode( int mode );
> 
> Until now the cursor in input fields (when it got the focus
> by a non-mouse event, e.g. by pressing the <Tab> key, was
> set to the end of an existing string at first and, when you
> go there another time, to the position it had when you left
> the input field. And for input fields with an upper limit of
> characters (set vie fl_set_input_maxchars()) you couldn't
> enter any more characters when the limit was reached, you
> first had to delete at least one. This is still the default.
> 
> But by using fl_set_input_mode() with an argument of
> 'FL_DOS_INPUT_MODE' you can now set the behaviour to some-
> thing more in line with what you may be used to from DOS pro-
> grams showing some input forrms: the cursor is always put into
> the start of the field when you "tab into" it. And for input
> field with an upper limit on the number of characters it can
> hold when it becomes "full" and you try to insert more charac-
> ters somewhere before the end characters at the end get
> "shiiftet out" to make room for the new characters.
> 
> This setting is global for whole the application and you can
> switch back to "normal" mode by calling fl_set_input_mode()
> with an argument of 'FL_NORMAL_INPUT_MODE'.
> 
> I guess you don't have to test this new function too much since
> Serge already has done that;-)
> 
> I guess we're on the home stretch for the new "real" (i.e. not
> just pre-) release now, so anyone who has noticed anything not
> working to specs please speak up! (And a simple "everything seems
> to be working fine here" message will boost my confi- dence that
> we're ready to get the new version out of the door;-)
> 
>                           Best regards, Jens
> -- 
>   \   Jens Thoms Toerring  ________      address@hidden
>    \_______________________________      http://toerring.de

-- 
  Michal Szymanski (msz at astrouw dot edu dot pl)
  Warsaw University Observatory, Warszawa, POLAND