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

[address@hidden]

Hi Jens and Serge,
My 2c here is maybe adding a new flag is the best way to resolve this apparent 
unreconcilable difference in expectations. 
Regards,
TC   

Sent from my iPhone

On May 15, 2010, at 4:01 PM, Jens Thoms Toerring <address@hidden> wrote:

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