Re: [Fwd: Re: address@hidden: Re: [XForms] fl_set_input_return(ob, FL_RETURN_ALWAYS); ]]

[Jens Thoms Toerring]

Hi Serge,

On Sat, May 15, 2010 at 12:51:00PM -0400, Serge Bromow wrote:

<my starting part of the conversation mostly snipped>

> >But now comes the "strange" behaviour with 1.0.90. The user
> >enters some value in one of the fields and presses "Close".
> >But the new value is never set since my program doesn't get
> >notified that editing stopped and thus can't make toolbox_wait()
> >return to the script for that input field. The user, of course,
> >reports this as a bug - (s)he set a new value but it never made
> >it to the device. Now, I now can start to expain to him or her,
> >that, when the "Close" button is pressed, the changes made to
> >the last input field aren't reported back and, in order to get
> >around that, there are only two "fixes":
> >
> > a) Before (s)he presses "Close" (s)he has to move the cursor
> >    into another input field (or press <TAB>, at least if there
> >    is only a single input field) and has to tell his/her col-
> >    legues who also may use the script.
> >
> > b) Alternatively, when the "Close" button has been pressed
> >    (s)he must add lines for sending each of the values again
> >    to the device
> or c) You check any changes to input field on close and perform the
> update for them.

Actually, that's what I can't. Remember that all that is
controlled by a script that my program just interprets. To
add reasonable actions on the behalf of the writer of the
script my program would have to understand the "meaning"
of the code in the script - and that would require a big
step from a simple interpreter to full artificial intelli-
gence. My program just reads in a line from the script and
interprets it in the sense that e.g.

     lockin_amplifier_phase( 178 );

makes it call the function from the lockin amplifier module
for setting the phase. But it isn't "aware" that it talks
with the lockin amplifier module and what the consequences
are, it mostly just translates a string of text into a set
of function calls. It's hardly "aware" of even interpreting a
loop (except that it knows that at some line it has to jump
back a few lines) but what the purpose of the loop is is far
beyond it. So there is no way at all (except perhaps by spen-
ding the next few years writing an expert system for "under-
standing" scripts written in my little scripting language;-)
to get around this problem. And I fear my programming abili-
ties aren't up to that task...

> >I see it exactly the other way round: each object should do its
> >stuff, regardless of any other objects that may exist. When an
> >input object notices that editing has ended and it's set up to
> >send a notification under this condition then it should do that,
> >whatever the reasons editing ended are. If you make the reaction
> >of one object dependent on what other objects exist or do I feel
> >that we might end up with an extremely compicated set of rules
> >that nobody will be able to understand fully anymore. And there-
> >fore I personally consider the behaviour in 1.0.90 and before to
> >be broken.

> This is the crux of our discussion.
> 1st - We differ in what we consider END. I see it as TAB or ENTER or
> MOUSE FOCUS  to another input object. You added ANY OTHER
> interaction to this list. The change of interaction to another input
> object is valid but I disagree when focus moves to a NON input
> field. I do not consider this END of input interaction. Rather I see
> this as new interaction.

I absolutely agree, that's exactly the difference in our points
of views;-)

> 2nd - Input object are unique in they allow for keyboard interaction
> and should be treated as unique. No simple object interaction rule
> here. That is to say they may not follow the sames rules as simple
> mouse events.

Also other object may react to keyoard input, e.g. via keyboard
shortcuts. And I don't see compelling reason to treat input ob-
jects differentlty from other objet types. All objects are a
little different, why single out input objects?

> 3rd - I believe that user interaction should always supersede
> previous xfroms directives. (like callbacks) The Human is the
> driving force for interactive request and should be.

I don't understand what this is aiming at. And, well, the user
is who's doing the interaction, but your program has to deal
with it;-)

> 4th - I believe we violate a basic principal by having
> fl_do/check_forms() return more than 1 object per interaction. This
> is a big one for me.

As far as I can see other toolkits I have been dealing with
also treat clicking e.g. on a button as "end of interaction"
with the input object. I'm currently working with Qt and there,
when you have been in an input field and then click on a button
a "editingFinished()" signal (Qt's equivalent of the object
getting returned in XForms) gets send from the input field.
They even go a step further in that the input field doesn't
get back the focus (i.e. the cursor isn't reappearing in the
input field after the mouse click) - not unreasonably in my
mind since it's a visual clue that the value of the input field
has been accepted by the program (and actions that may be bound
to the input field have been executed).

Of course, what others do isn't necessarily a measure of what's
right and what's wrong. But in this case I tend to think that
how Qt is doing it (and other toolkits seem to do it) is correct
and logical and what we had in XForms was simply a bug.

> More on this later.
> >I admit that input objects are standing out a bit in the whole
> >scheme for two reasons: they have a long interaction time and
> >the focus seems to be in one of them all of the time, even during
> >interaction with other, non-input objects.
> Yes input objects are an curious beast.
> > But the latter is an
> >illusion, they lose the focus for the (short) interaction time
> >with the other object, but normally get it back immediately once
> >that interaction has ended.
> >
> Or should not get back the focus if the program moves on to other tasks.

I would subscribe to that when you mean by "other tasks" clicking
on some other object. That's how e.g. Qt is doing it and I find
it rather intuitive for the user. But that would be a change going
even further than the change we are currently discussing. But I'm
always open to suggestions...

> Here  is a code view of what I mean;
> while(1) {
>     ob = fl_do_forms();
> 
>    if( ob == exitob ) {
>       exit(0);
>       }
> 
>    if( ob == inputob ) {
>       if( perform_test() == FAIL ) {
>             "warn user"
>             }
>       }
> }
> 
> If perform_test() is valid or not I cannot stop the program from
> doing exit(0). I can, but more kludge code is required.
> 
> Here is the same code with proper checking;
> while(1) {
>     ob = fl_do_forms();
> 
>    if( ob == exitob ) {
>        if( perform_test() == FAIL ) {
>           continue;
>           }
>       exit(0);
>       }
> 
>    if( ob == inputob ) {
>       perform_test();
>       }
> }
> The inputob object being called in advance of the exitob has no
> useful purpose.

In this case, yes, because all you (or the user) want is to
"get out of here". And you wouldn't need to call perform_test()
in the exit button branch by using a boolean flag instead, so
it might look less "kludgy", e. g

inputs_ok = ! FAIL;
while ( 1 ) {
    ob = fl_do_forms( );

    if ( inputs_ok && ob == exitob )
        exit( 0 );
 
    if ( ob == inputob )
        inputs_ok = perform_test( );
}

But if the user having edited an input field would have conse-
quences (say a side effects like setting the output power of a
50 kW RF amplifier from full power to the 0 W the user entered
as the last action before clicking on the exit button) then the
situation might look a bit different. In that case you wouldn't
have to call perform test() but perhaps do a lot of other stuff
after the 

    if ( ob == inputob ) {

line. Before you react to the exit button by calling exit(0) you
have to check for all input objects if the user made changes to
them before pressing the exit button since you don't get any
notice that this was what the user did before. And for that you
would have to additionally keep track of the contents of all the
input objects externally to the input objects (otherwise how could
you figure out which one got changed last?) and repeat a good deal
of the code you already have in the branch for the input objects.
That would make a simple "get me out of here" call of exit() into
something vastly more complex...

So to me this looks like an example that tends to supports my
point of view;-)

> Yes indeed there are valid points. On both sides. We both could go
> on finding solutions to the fl_input problem and fl_do_forms()
> return rules but there are more important issues at stake than
> coding techniques or semantics.
> 
> 1st - By making changes like this the library risks breaking a lot
> of code.  In my case alone I find over 250 instance where I
> implicitly set the  input behaviour to RETURN_END and RETURN_ALWAYS.
> None expect to see 2 object returns.

> 2nd - Before making changes there should be some discussion. A
> search of the current archive yields no results for FL_RETURN. There
> may have been something before. Right now you and I are having this
> discussion. It is not being posted to the list for other peoples
> input. Maybe we should post the last few e-mail to the group to gain
> other perspective.

Well, the change was made more than two years ago in the run-up
to version 1.0.91. Here's the entry in the ChangeLog file:

  2008-03-26 Jens Thoms Toerring    <address@hidden>
  
      * lib/forms.c: Clicking on a "pushable" object now
      leads to an input object currently having the focus
      lose the focus, thus enforcing it to report changes.
      Until now this only happened if the object that was
      clicked on was another input object.

And I announced it in my post to the mailing list in the 
list of changes when making the 1.0.91pre3 pre-release on
the same day

http://xforms-toolkit.org/old-archive/2008/000702.html

a) Input objects now lose the focus (and report changes back
   to the program) on clicks of other objects that accept a
   click with the mouse (buttons, sliders, etc.). This gets
   around the problem that if you had an input field, edited
   something in there (without hitting the ENTER or TAB key)
   and then clicked on some button that's supposed to make
   use of what just had got entered into the input field, the
   function fl_get_input() still returned the unchanged value
   since the input field never lost its focus and thus didn't
   accept the changes you made.

Neither in the time until the release of 1.0.91 (2008/11/26)
nor afterwards somebody seem to have been bothered be the
change, so I hadn't the impression that there was any urgent
demand for discussions. One problem now with going back to the
old 1.0.90 behaviour now might be that it could interfer with
programs written with the new behaviour in mind.

> I understand that in your particular case the changes to fl_input
> code change made sense and it may for other instances but since
> there are programing approaches to your problem they should be used
> before altering the library to suite a particular condition.

As I tried to describe above, in my particular case there simply
isn't a way around the issue I can see (short of developing AI;-).

> Now all of that said we need a solution.

Yes;-)

> Here is my self serving possible solution.
> 
> We return RETURN_END and RETURN_ALWAYS to there previous behaviour.
> That is to say they do not return when other interaction takes place
> except moving to another input field.
> 
> Side Bar:
> I see you have added more RETURN values than were available in
> 1.0.90. I just tried FL_RETURN_END_CHANGED which I tough would give
> me what I need thus leaving your changes alone. Return on input,
> return on end and do not return on other interaction. But it only
> return on END not on CHANGE.

These aren't actually "new" RETURN values, they all existed and
were documented (inculding for the input objects) already in the
documentation for 0.89. The only new RETURN values I added are
FL_RETURN_SELECTION and FL_RETURN_DESELECTION, but which only
extend what you can set for a browser and which I felt where
sourly missing.

> Since you have new classes of returns then maybe you could add
> RETURN_ABSOLUTE or RETURN_PEDANTIC. Always return regardless of
> other interaction.

Actually, we would need extra RETURN settings for the three

FL_RETURN_END_CHANGED
FL_RETURN_END
FL_RETURN_ALWAYS

But, of course, one could also OR them with a new flag only for
the input objects.

> This would return expected behaviour

May I insert "expected by you"? At least for me it never
was expected, just the other way round. I found out about
it only when getting bitten badly by it and always consi-
dered it to be a bug. That's why I changed it rather soon
after starting to dabble with the XForms sources.

> for previous build applications
> and provide the type of return you require. Who knows I may benefit
> from such a RETURN in the future.

To be honest, I am reluctant to go back to a behaviour that
looks to me just like a bug. And I find the old behaviour
to be counterintuitive since it treats input objects diffe-
rently from all other object types.

May I make a counter-proposal, also, of course, a bit self-
serving?;-) I add a new flag you can OR with what you pass to
fl_set_object_return() for input objects that you want to have
the old, buggy behaviour instead of the other way round?

I am looking forward to others helping us argue;-)

                            Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de