Re: [XForms] New prerelease xforms-1.0.94pre16

[Jens Thoms Toerring]

Hi Michal.

On Thu, Jan 03, 2013 at 10:16:21AM +0100, Michal Szymanski wrote:
> 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.

Its indeed a bit of a question of taste - one may argue that
a deactivated object is "playing dead", so also tooltips
shouldn't be shown. But on the other hand other toolkits also
show tooltips for deactivated objects, so I revert this change
and only mke sure tooltips aren't shown for invisibe objects
(then, I guess, showing a tooltip is just annoying).

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

How do you get that behaviour at all? For me always the very
first line of the directory list is shown when I open up a
file selector again (and I never have given it a thought;-),
not something around the file I had selected before. So I'm
a bit confused were to start looking when trying to make
that improvement. Understanding how yu managed to get that be-
haviour would be helpful.

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

That isn't happening for me - the output files don't contain
anything about one of the buttons being set after testing a
set of radio buttons (even if one of the looks like it would
be set - that's a drawback of the design of re-using the ob-
jects for testing and thus the appearances can get a bit out
of sync). And if you really must switch off a button then, in
the attributes form (tab "Spec", look for the "Initially set"
check button) you can make sure what the state of the button
is (and what then gets written to the files). At least that's
how it seems to work for me...

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

A full modification of the code that would check if an object
really was changed at all when the "Accept" button is pressed
would require a lot of effort - there's no book-keeping at the
moment of changes made and adding that would probably require
weeks;-) Thus I just changed it that when the "Cancel" button
is pressed (or the <Esc> key is used to close the form for the
objects attributes) the object (and thus the from it belongs
to) remains to be considered as unchanged. I hope that's at
least better than nothing.
                             Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de