Re: MVC comments

[Allan Rae]

On Fri, 6 Apr 2001, John Levon wrote:
[...]
 Let me get specific. I have a button in Citation, "Add", that should
 be enabled if the doc is read-write, disabled if not. However, there
 is *also* the rule that it should *not* be enabled if there is no
 selection in the available-citations listbox. Now adding it as
 addReadOnly() will enable the button, as the doc is read-write, but in
 fact I might need it disabled, so I have to turn it off again.

 I think you suggested earlier that in this case, the button should not
 be added as addReadOnly(). This means I have to my own readonly
 checking everywhere, and seems a little bit ugly; in fact, it makes
 the buttoncontroller not very useful at all ...

 I hope that explains *my* problem

Okay then this should be fixable with the RBG/enum extension -- once I get
time to work on it again.  Not today.  Maybe tomorrow, more likely
Wednesday.  I think I'll just start again from scratch since I've decided
the old way I was trying to do it was too complicated and we need a more
general solution.

Allan. (ARRae)

Re: MVC comments

[Allan Rae]

On Fri, 6 Apr 2001, John Levon wrote:
[...]
> Let me get specific. I have a button in Citation, "Add", that should
> be enabled if the doc is read-write, disabled if not. However, there
> is *also* the rule that it should *not* be enabled if there is no
> selection in the available-citations listbox. Now adding it as
> addReadOnly() will enable the button, as the doc is read-write, but in
> fact I might need it disabled, so I have to turn it off again.
>
> I think you suggested earlier that in this case, the button should not
> be added as addReadOnly(). This means I have to my own readonly
> checking everywhere, and seems a little bit ugly; in fact, it makes
> the buttoncontroller not very useful at all ...
>
> I hope that explains *my* problem

Okay then this should be fixable with the RBG/enum extension -- once I get
time to work on it again.  Not today.  Maybe tomorrow, more likely
Wednesday.  I think I'll just start again from scratch since I've decided
the old way I was trying to do it was too complicated and we need a more
general solution.

Allan. (ARRae)

Re: MVC comments

[John Levon]

On Fri, 6 Apr 2001, Allan Rae wrote:

 On Thu, 5 Apr 2001, John Levon wrote:
 
  On Thu, 5 Apr 2001, Allan Rae wrote:
 
   That's what the input checking routine is for.
  
   The fact that an input has changed isn't significant.  The problem is
   whether or not that change has resulted in a valid contents of the dialog
   or not.  If the contents are valid then Okay and Apply should be
   enable-able (if the state machine is in an appropriate state).
 
  The problem for me is that this also enables anything you added with
  addReadOnly, if the dialog is read-write. Ideally these two things
  should be split somehow, I'm sure you two controller bods can come up
  with something clever that works ;)
 
 I don't understand why this is a problem.  If we have a read-write
 document then all the read-only list widgets should be enabled.  What
 operation are you expecting?
 
 Do you want some widgets that are only enabled when we have a read-only
 document?

no. It's not a conceptual problem.

Let me get specific. I have a button in Citation, "Add", that should be enabled
if the doc is read-write, disabled if not. However, there is *also* the rule
that it should *not* be enabled if there is no selection in the available-citations
listbox. Now adding it as addReadOnly() will enable the button, as the doc is 
read-write,
but in fact I might need it disabled, so I have to turn it off again.

I think you suggested earlier that in this case, the button should not be added as 
addReadOnly().
This means I have to my own readonly checking everywhere, and seems a little bit ugly; 
in fact,
it makes the buttoncontroller not very useful at all ...

I hope that explains *my* problem

john

-- 
"I am a conscientious man, when I throw rocks at seabirds I leave no tern
unstoned."
   - Ogden Nash

Re: MVC comments

[John Levon]

On Fri, 6 Apr 2001, Allan Rae wrote:

> On Thu, 5 Apr 2001, John Levon wrote:
> 
> > On Thu, 5 Apr 2001, Allan Rae wrote:
> >
> > > That's what the input checking routine is for.
> > >
> > > The fact that an input has changed isn't significant.  The problem is
> > > whether or not that change has resulted in a valid contents of the dialog
> > > or not.  If the contents are valid then Okay and Apply should be
> > > enable-able (if the state machine is in an appropriate state).
> >
> > The problem for me is that this also enables anything you added with
> > addReadOnly, if the dialog is read-write. Ideally these two things
> > should be split somehow, I'm sure you two controller bods can come up
> > with something clever that works ;)
> 
> I don't understand why this is a problem.  If we have a read-write
> document then all the read-only list widgets should be enabled.  What
> operation are you expecting?
> 
> Do you want some widgets that are only enabled when we have a read-only
> document?

no. It's not a conceptual problem.

Let me get specific. I have a button in Citation, "Add", that should be enabled
if the doc is read-write, disabled if not. However, there is *also* the rule
that it should *not* be enabled if there is no selection in the available-citations
listbox. Now adding it as addReadOnly() will enable the button, as the doc is 
read-write,
but in fact I might need it disabled, so I have to turn it off again.

I think you suggested earlier that in this case, the button should not be added as 
addReadOnly().
This means I have to my own readonly checking everywhere, and seems a little bit ugly; 
in fact,
it makes the buttoncontroller not very useful at all ...

I hope that explains *my* problem

john

-- 
"I am a conscientious man, when I throw rocks at seabirds I leave no tern
unstoned."
   - Ogden Nash

Re: MVC comments

[Allan Rae]

On Tue, 3 Apr 2001, Allan Rae wrote:

 On Mon, 2 Apr 2001, Angus Leeming wrote:
   7) I find it a bit weird that I call a method "valid(bool)" whenever
   e.g. a user types another character in a line edit widget. Can we
   add another method mutated(bool) or changed(bool) possibly ?
   This would make at least the KDE frontend code a lot clearer IMHO

 There's more than simply "changed/unchanged".  valid() should only be
 called when a change has happened.  So it represents "valid
 changed/invalid changed".   You are also free to call bc.input(SMInput)
 directly.

BTW, what happens if after the user presses a key they then try to press
Okay?  If the last key press in the edit box gave an invalid entry then
they shouldn't have an Okay button available.  Sure it's possible to
register input filter functions for edit boxes or other inputs with xforms
and I imagine most toolkits allow this also.  So it should be possible to
ensure any input field always contains valid characters but what about
what that input represents in combination with other widgets?  It's
possible to enter an input using all the valid characters for an input and
still not have a valid entry: does the directory really exist and is
writeable (in Preferences) or the font sizes aren't in ascending sizes
(again in Preferences).

That's what the input checking routine is for.

The fact that an input has changed isn't significant.  The problem is
whether or not that change has resulted in a valid contents of the dialog
or not.  If the contents are valid then Okay and Apply should be
enable-able (if the state machine is in an appropriate state).

Allan. (ARRae)

Re: MVC comments

[Juergen Vigna]

On 05-Apr-2001 Allan Rae wrote:

 - outputs_[INITIAL] = CLOSE;
 + outputs_[INITIAL] = OKAY | APPLY | CLOSE;
 
 This should be a safe change for both these policies.  It'd also mean that
 after a Restore you can still press Okay or Apply without changing
 something in the dialog.
 
 Provided we do an input check on the contents of the dialog just as it is
 being shown then we can move to the appropriate state (INVALID or
 RO_INVALID) if the contents aren't initially valid.  I suspect we assume
 that the contents are always valid on initial showing.
 

Well we would need OKAY | APPLY only if the cursor moves to some other
paragraph isn't it or in general if the cursor moves. We should send a
update signal to buffer dependent dialogs but for this type of dialog we
would need one more signal and that is a signal which activates that buttons
if one of the parameters of the actual paragraph differs with the content
of the actual cursor position (or in the case of the ParagraphLayout the
paragraph we are actually in). Also it would be great to have:

1. A button in the Dialog to update the contents with the actual paragraph
   (or whatever) settings.

2. An other way to realize this. Mayby just reopening the dialog (also
   without closing it first) should do this. Otherwise if I want to change
   only one thing in a paragraph I have to close the Dialog and reopen it
   when the cursor is inside the paragraph to have the Dialog with the
   right values.

Comments?!

Jrgen

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jrgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

You'd like to do it instantaneously, but that's too slow.

Re: MVC comments

[Angus Leeming]

On Thursday 05 April 2001 05:47, Allan Rae wrote:
  Yes, this is a fudge to a lacking ButtonPolicy. Consider inputting a
  citation-inset from the minibuffer. The params are perfectly valid, the
  dialog pops up. Do you want to "Apply" them? Yes I do!
 
 Doesn't the citation inset already exist at that stage with those values?
 You're more familiar with this process than I am since you reworked a lot
 of it.

Here's the rule: 
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg21186.html
(points 2 and 4) Currently, none of the insets conform to it exactly, but 
many (most) do so almost. Eventually, they all will.

But basically, no, the inset does not exist when the dialog is launched from 
the minibuffer.

 I think this is the problem we've discussed before about the
 OkApplyCancel[ReadOnly]Policy.  I think it would probably make sense to:
 
 - outputs_[INITIAL] = CLOSE;
 + outputs_[INITIAL] = OKAY | APPLY | CLOSE;
 
 This should be a safe change for both these policies.  It'd also mean that
 after a Restore you can still press Okay or Apply without changing
 something in the dialog.
 
 Provided we do an input check on the contents of the dialog just as it is
 being shown then we can move to the appropriate state (INVALID or
 RO_INVALID) if the contents aren't initially valid.  I suspect we assume
 that the contents are always valid on initial showing.

Hmmm. So we should have

void ControlSomeDialog::show()
{
bc.valid(isValid(params()));
view().show();
}
void ControlSomeDialog::update()
{
bc.valid(isValid(params()));
view().update();
}
So, another reqirement of the Params struct: it should have an isValid() 
memeber function too.

 I'd enjoy being back.  I'll have to get familiar with the code again
 though.  So much has changed.  You blokes, and you in particular Angus,
 have been doing a terrific job.

Most of the change is superficial; moving stuff out of one class and into 
two. It's worth while trying to understand the control flow, but all Views 
see exactly the same flow, even though there are two generic controllers, 
ControlInset and ControlDialog. If you can think of a better name for 
ControlDialog, then shout it out!

A

Re: MVC comments

[John Levon]

On Thu, 5 Apr 2001, Allan Rae wrote:

 That's what the input checking routine is for.
 
 The fact that an input has changed isn't significant.  The problem is
 whether or not that change has resulted in a valid contents of the dialog
 or not.  If the contents are valid then Okay and Apply should be
 enable-able (if the state machine is in an appropriate state).

The problem for me is that this also enables anything you added with addReadOnly,
if the dialog is read-write. Ideally these two things should be split somehow,
I'm sure you two controller bods can come up with something clever that works ;)

thanks
john

-- 
"Be conservative in what you do, be liberal in what you accept from others."
- Jon Postel

Re: MVC comments

[Angus Leeming]

On Thursday 05 April 2001 08:41, Juergen Vigna wrote:
 On 05-Apr-2001 Allan Rae wrote:
 
  - outputs_[INITIAL] = CLOSE;
  + outputs_[INITIAL] = OKAY | APPLY | CLOSE;
  
  This should be a safe change for both these policies.  It'd also mean that
  after a Restore you can still press Okay or Apply without changing
  something in the dialog.
  
  Provided we do an input check on the contents of the dialog just as it is
  being shown then we can move to the appropriate state (INVALID or
  RO_INVALID) if the contents aren't initially valid.  I suspect we assume
  that the contents are always valid on initial showing.
  
 
 Well we would need OKAY | APPLY only if the cursor moves to some other
 paragraph isn't it or in general if the cursor moves. We should send a
 update signal to buffer dependent dialogs but for this type of dialog we
 would need one more signal and that is a signal which activates that buttons
 if one of the parameters of the actual paragraph differs with the content
 of the actual cursor position (or in the case of the ParagraphLayout the
 paragraph we are actually in). Also it would be great to have:
 
 1. A button in the Dialog to update the contents with the actual paragraph
(or whatever) settings.
 
 2. An other way to realize this. Mayby just reopening the dialog (also
without closing it first) should do this. Otherwise if I want to change
only one thing in a paragraph I have to close the Dialog and reopen it
when the cursor is inside the paragraph to have the Dialog with the
right values.
 
 Comments?!

Well, the inset dialogs automatically update when you click on a new inset 
because the inset emits a signal in InsetXXX:Edit() that's picked up by the 
dialog.

You could emit a signal whenever the user clicks in a new paragraph. That way 
we wouldn;t need an update button at all.

Or is this too easy?

Angus

Re: MVC comments

[Allan Rae]

On Thu, 5 Apr 2001, Angus Leeming wrote:

 On Thursday 05 April 2001 07:31, Allan Rae wrote:
  BTW, what happens if after the user presses a key they then try to press
  Okay?  If the last key press in the edit box gave an invalid entry then
  they shouldn't have an Okay button available.

 I've been thinking about (note no intention of implementing!) invalid input.

 When data is input to the button controller as invalid, why not then store a
 pointer to that widget in a vector of invalid data. Future input is checked
 against this vector and any (was invalid, now valid) data is removed from it.
 The dialog can then only be activated when all input is valid.

Then what do you do if it's the relationship between two inputs that is
wrong.  Like the font size settings in Preferences.  These are currently
restricted to being monotonic increasing (although consecutive sizes can
be the same size).

The way I had originally written the input() handling routine in the
dialogs I ported was that it checks _all_ these relationships _everytime_
it's called.  Now there seem to be a few dialogs that only do checks for
individual widgets or at least for individual tabs of a tabbed dialog.
Where possible I think we should use a specific input filter on an
input/edit box to control what characters can be entered etc.  Several of
these already exist for xforms and much of their implementation could be
shared with other toolkits.  The overhead of input() operating the way
I described is negligable because this is triggered by a user typing or
clicking.

So maybe I should more clearly define what I expected in my design of BC.
The output of the dialog.input() processing callback defines whether the
dialog is in a valid state or not.  Angus has extended this to allow it
say no change in previous state -- this was for handling cases where a
user clicked on a widget that had no effect upon the dialog state.

This should only be needed when input checking is shortcutted or at least
"optimized" but even then you still run into problems of tracking.

My original plan called for input() to check everything that could make a
dialog invalid.  This was to work in conjunction with input-filtering
where possible.  Under XForms all you can effectively do with an
input-filter is return a bool flag of whether that input/keypress is valid
or not.  You can't do anything particularly tricky with it.

So input() checks relationships between inputs and checks other
requirements that you can't do in an input-filter.  For example, typing in
a writable directory name: input-filtering lets you check for valid
filename characters but you can't do a check of whether or not the
directory exists in the input-filter because if you return FL_INVALID the
character isn't even entered in the input box making it impossible to
enter anything in the box!

If you want to get fancy and limit input checking to particular tabs of a
tabbed dialog or individual widgets (the one the user just typed in for
instance) then you need to do some invalid tracking.  I have been
considering inverting the input box colours or just changing
it's background to red to make it more obvious to users which ones we
think they've gotten wrong.  This also needs some sort of tracking or at
least reset to normal every time through when they are valid.

Personally, I'd rather process everything, everytime, until such time as
we start seeing interactive response problems.

[at this point I decided to take a look at FormPreferences.C instead of
 just seeing how BC and co. where implemented]

Looking through FormPreferences.C I now see that the input() callback is
now being used as a general purpose callback and the object that triggered
the callback is being used to do all sorts of things from input checking
to running commands.  I have this to say about that:

NNN  NNIII
 NN   OO  OO   III
NN   OOOO  III
NN  NNN   OO  OO
NN   NNOOO

Clearly,  there's been a misunderstanding of how I'd intended this to work
and I hadn't noticed how this was being altered in my absence.

Personally, I'd rather things like FormPreferences::Converters::Add() got
their own callback.  Direct to the function associated with the button --
which was why I'd written those callback macros in the first place. The
button doesn't need any input checking because it isn't an input. Only
inputs (like input boxes, sliders/counters and edit boxes) need to be
calling input(). Sigh, sigh again. [Obsenity deleted].

I really don't like the idea of centralizing the callbacks and then trying
to figure out who does what as a result.  There's a mixture of control and
input processing being done now in what was intended to be an input-only
processing step.  As a result you can't give BC a proper response and
people are getting frustrated.  If you really, really like the idea of a
centralized _control_ callback then I would suggest that you create one.
Call 

Re: MVC comments

[Allan Rae]

On Thu, 5 Apr 2001, John Levon wrote:

 On Thu, 5 Apr 2001, Allan Rae wrote:

  That's what the input checking routine is for.
 
  The fact that an input has changed isn't significant.  The problem is
  whether or not that change has resulted in a valid contents of the dialog
  or not.  If the contents are valid then Okay and Apply should be
  enable-able (if the state machine is in an appropriate state).

 The problem for me is that this also enables anything you added with
 addReadOnly, if the dialog is read-write. Ideally these two things
 should be split somehow, I'm sure you two controller bods can come up
 with something clever that works ;)

I don't understand why this is a problem.  If we have a read-write
document then all the read-only list widgets should be enabled.  What
operation are you expecting?

Do you want some widgets that are only enabled when we have a read-only
document?

Hmmm... okay maybe this is the shared management problem again.  If I can
get this RBG [RadioButtonGroup] patch working we should be able to define
a RBG then toggle different radio buttons to get different sets of widgets
activated/deactivated.

Then I can generalize the patch to only use a set of ints rather than a
whole RBG (hh maybe I should do this now it might make it easier to
get working).  That'd allow you to define within your dialog an enum to
define the sets of widgets that can be activated together and inform the
BC when the enum state changes. bc().refresh() then activates the
appropriate widgets -- the dialog just has to track which set should be
active.  Hmmm yeah I think that'd probably be easier to implement than the
RBG specific thing I put on ice months ago.

Allan. (ARRae)

Re: MVC comments

[Allan Rae]

On Tue, 3 Apr 2001, Allan Rae wrote:

> On Mon, 2 Apr 2001, Angus Leeming wrote:
> > > 7) I find it a bit weird that I call a method "valid(bool)" whenever
> > > e.g. a user types another character in a line edit widget. Can we
> > > add another method mutated(bool) or changed(bool) possibly ?
> > > This would make at least the KDE frontend code a lot clearer IMHO
>
> There's more than simply "changed/unchanged".  valid() should only be
> called when a change has happened.  So it represents "valid
> changed/invalid changed".   You are also free to call bc.input(SMInput)
> directly.

BTW, what happens if after the user presses a key they then try to press
Okay?  If the last key press in the edit box gave an invalid entry then
they shouldn't have an Okay button available.  Sure it's possible to
register input filter functions for edit boxes or other inputs with xforms
and I imagine most toolkits allow this also.  So it should be possible to
ensure any input field always contains valid characters but what about
what that input represents in combination with other widgets?  It's
possible to enter an input using all the valid characters for an input and
still not have a valid entry: does the directory really exist and is
writeable (in Preferences) or the font sizes aren't in ascending sizes
(again in Preferences).

That's what the input checking routine is for.

The fact that an input has changed isn't significant.  The problem is
whether or not that change has resulted in a valid contents of the dialog
or not.  If the contents are valid then Okay and Apply should be
enable-able (if the state machine is in an appropriate state).

Allan. (ARRae)

Re: MVC comments

[Juergen Vigna]

On 05-Apr-2001 Allan Rae wrote:

> - outputs_[INITIAL] = CLOSE;
> + outputs_[INITIAL] = OKAY | APPLY | CLOSE;
> 
> This should be a safe change for both these policies.  It'd also mean that
> after a Restore you can still press Okay or Apply without changing
> something in the dialog.
> 
> Provided we do an input check on the contents of the dialog just as it is
> being shown then we can move to the appropriate state (INVALID or
> RO_INVALID) if the contents aren't initially valid.  I suspect we assume
> that the contents are always valid on initial showing.
> 

Well we would need OKAY | APPLY only if the cursor moves to some other
paragraph isn't it or in general if the cursor moves. We should send a
update signal to buffer dependent dialogs but for this type of dialog we
would need one more signal and that is a signal which activates that buttons
if one of the parameters of the actual paragraph differs with the content
of the actual cursor position (or in the case of the ParagraphLayout the
paragraph we are actually in). Also it would be great to have:

1. A button in the Dialog to update the contents with the actual paragraph
   (or whatever) settings.

2. An other way to realize this. Mayby just reopening the dialog (also
   without closing it first) should do this. Otherwise if I want to change
   only one thing in a paragraph I have to close the Dialog and reopen it
   when the cursor is inside the paragraph to have the Dialog with the
   right values.

Comments?!

Jürgen

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

You'd like to do it instantaneously, but that's too slow.

Re: MVC comments

[Angus Leeming]

On Thursday 05 April 2001 05:47, Allan Rae wrote:
> > Yes, this is a fudge to a lacking ButtonPolicy. Consider inputting a
> > citation-inset from the minibuffer. The params are perfectly valid, the
> > dialog pops up. Do you want to "Apply" them? Yes I do!
> 
> Doesn't the citation inset already exist at that stage with those values?
> You're more familiar with this process than I am since you reworked a lot
> of it.

Here's the rule: 
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg21186.html
(points 2 and 4) Currently, none of the insets conform to it exactly, but 
many (most) do so almost. Eventually, they all will.

But basically, no, the inset does not exist when the dialog is launched from 
the minibuffer.

> I think this is the problem we've discussed before about the
> OkApplyCancel[ReadOnly]Policy.  I think it would probably make sense to:
> 
> - outputs_[INITIAL] = CLOSE;
> + outputs_[INITIAL] = OKAY | APPLY | CLOSE;
> 
> This should be a safe change for both these policies.  It'd also mean that
> after a Restore you can still press Okay or Apply without changing
> something in the dialog.
> 
> Provided we do an input check on the contents of the dialog just as it is
> being shown then we can move to the appropriate state (INVALID or
> RO_INVALID) if the contents aren't initially valid.  I suspect we assume
> that the contents are always valid on initial showing.

Hmmm. So we should have

void ControlSomeDialog::show()
{
bc.valid(isValid(params()));
view().show();
}
void ControlSomeDialog::update()
{
bc.valid(isValid(params()));
view().update();
}
So, another reqirement of the Params struct: it should have an isValid() 
memeber function too.

> I'd enjoy being back.  I'll have to get familiar with the code again
> though.  So much has changed.  You blokes, and you in particular Angus,
> have been doing a terrific job.

Most of the change is superficial; moving stuff out of one class and into 
two. It's worth while trying to understand the control flow, but all Views 
see exactly the same flow, even though there are two generic controllers, 
ControlInset and ControlDialog. If you can think of a better name for 
ControlDialog, then shout it out!

A

Re: MVC comments

[John Levon]

On Thu, 5 Apr 2001, Allan Rae wrote:

> That's what the input checking routine is for.
> 
> The fact that an input has changed isn't significant.  The problem is
> whether or not that change has resulted in a valid contents of the dialog
> or not.  If the contents are valid then Okay and Apply should be
> enable-able (if the state machine is in an appropriate state).

The problem for me is that this also enables anything you added with addReadOnly,
if the dialog is read-write. Ideally these two things should be split somehow,
I'm sure you two controller bods can come up with something clever that works ;)

thanks
john

-- 
"Be conservative in what you do, be liberal in what you accept from others."
- Jon Postel

Re: MVC comments

[Angus Leeming]

On Thursday 05 April 2001 08:41, Juergen Vigna wrote:
> On 05-Apr-2001 Allan Rae wrote:
> 
> > - outputs_[INITIAL] = CLOSE;
> > + outputs_[INITIAL] = OKAY | APPLY | CLOSE;
> > 
> > This should be a safe change for both these policies.  It'd also mean that
> > after a Restore you can still press Okay or Apply without changing
> > something in the dialog.
> > 
> > Provided we do an input check on the contents of the dialog just as it is
> > being shown then we can move to the appropriate state (INVALID or
> > RO_INVALID) if the contents aren't initially valid.  I suspect we assume
> > that the contents are always valid on initial showing.
> > 
> 
> Well we would need OKAY | APPLY only if the cursor moves to some other
> paragraph isn't it or in general if the cursor moves. We should send a
> update signal to buffer dependent dialogs but for this type of dialog we
> would need one more signal and that is a signal which activates that buttons
> if one of the parameters of the actual paragraph differs with the content
> of the actual cursor position (or in the case of the ParagraphLayout the
> paragraph we are actually in). Also it would be great to have:
> 
> 1. A button in the Dialog to update the contents with the actual paragraph
>(or whatever) settings.
> 
> 2. An other way to realize this. Mayby just reopening the dialog (also
>without closing it first) should do this. Otherwise if I want to change
>only one thing in a paragraph I have to close the Dialog and reopen it
>when the cursor is inside the paragraph to have the Dialog with the
>right values.
> 
> Comments?!

Well, the inset dialogs automatically update when you click on a new inset 
because the inset emits a signal in InsetXXX:Edit() that's picked up by the 
dialog.

You could emit a signal whenever the user clicks in a new paragraph. That way 
we wouldn;t need an update button at all.

Or is this too easy?

Angus

Re: MVC comments

[Allan Rae]

On Thu, 5 Apr 2001, Angus Leeming wrote:

> On Thursday 05 April 2001 07:31, Allan Rae wrote:
> > BTW, what happens if after the user presses a key they then try to press
> > Okay?  If the last key press in the edit box gave an invalid entry then
> > they shouldn't have an Okay button available.
>
> I've been thinking about (note no intention of implementing!) invalid input.
>
> When data is input to the button controller as invalid, why not then store a
> pointer to that widget in a vector of invalid data. Future input is checked
> against this vector and any (was invalid, now valid) data is removed from it.
> The dialog can then only be activated when all input is valid.

Then what do you do if it's the relationship between two inputs that is
wrong.  Like the font size settings in Preferences.  These are currently
restricted to being monotonic increasing (although consecutive sizes can
be the same size).

The way I had originally written the input() handling routine in the
dialogs I ported was that it checks _all_ these relationships _everytime_
it's called.  Now there seem to be a few dialogs that only do checks for
individual widgets or at least for individual tabs of a tabbed dialog.
Where possible I think we should use a specific input filter on an
input/edit box to control what characters can be entered etc.  Several of
these already exist for xforms and much of their implementation could be
shared with other toolkits.  The overhead of input() operating the way
I described is negligable because this is triggered by a user typing or
clicking.

So maybe I should more clearly define what I expected in my design of BC.
The output of the dialog.input() processing callback defines whether the
dialog is in a valid state or not.  Angus has extended this to allow it
say no change in previous state -- this was for handling cases where a
user clicked on a widget that had no effect upon the dialog state.

This should only be needed when input checking is shortcutted or at least
"optimized" but even then you still run into problems of tracking.

My original plan called for input() to check everything that could make a
dialog invalid.  This was to work in conjunction with input-filtering
where possible.  Under XForms all you can effectively do with an
input-filter is return a bool flag of whether that input/keypress is valid
or not.  You can't do anything particularly tricky with it.

So input() checks relationships between inputs and checks other
requirements that you can't do in an input-filter.  For example, typing in
a writable directory name: input-filtering lets you check for valid
filename characters but you can't do a check of whether or not the
directory exists in the input-filter because if you return FL_INVALID the
character isn't even entered in the input box making it impossible to
enter anything in the box!

If you want to get fancy and limit input checking to particular tabs of a
tabbed dialog or individual widgets (the one the user just typed in for
instance) then you need to do some invalid tracking.  I have been
considering inverting the input box colours or just changing
it's background to red to make it more obvious to users which ones we
think they've gotten wrong.  This also needs some sort of tracking or at
least reset to normal every time through when they are valid.

Personally, I'd rather process everything, everytime, until such time as
we start seeing interactive response problems.

[at this point I decided to take a look at FormPreferences.C instead of
 just seeing how BC and co. where implemented]

Looking through FormPreferences.C I now see that the input() callback is
now being used as a general purpose callback and the object that triggered
the callback is being used to do all sorts of things from input checking
to running commands.  I have this to say about that:

NNN  NNIII
 NN   OO  OO   III
NN   OOOO  III
NN  NNN   OO  OO
NN   NNOOO

Clearly,  there's been a misunderstanding of how I'd intended this to work
and I hadn't noticed how this was being altered in my absence.

Personally, I'd rather things like FormPreferences::Converters::Add() got
their own callback.  Direct to the function associated with the button --
which was why I'd written those callback macros in the first place. The
button doesn't need any input checking because it isn't an input. Only
inputs (like input boxes, sliders/counters and edit boxes) need to be
calling input(). Sigh, sigh again. [Obsenity deleted].

I really don't like the idea of centralizing the callbacks and then trying
to figure out who does what as a result.  There's a mixture of control and
input processing being done now in what was intended to be an input-only
processing step.  As a result you can't give BC a proper response and
people are getting frustrated.  If you really, really like the idea of a
centralized _control_ callback then I would suggest that you 

Re: MVC comments

[Allan Rae]

On Thu, 5 Apr 2001, John Levon wrote:

> On Thu, 5 Apr 2001, Allan Rae wrote:
>
> > That's what the input checking routine is for.
> >
> > The fact that an input has changed isn't significant.  The problem is
> > whether or not that change has resulted in a valid contents of the dialog
> > or not.  If the contents are valid then Okay and Apply should be
> > enable-able (if the state machine is in an appropriate state).
>
> The problem for me is that this also enables anything you added with
> addReadOnly, if the dialog is read-write. Ideally these two things
> should be split somehow, I'm sure you two controller bods can come up
> with something clever that works ;)

I don't understand why this is a problem.  If we have a read-write
document then all the read-only list widgets should be enabled.  What
operation are you expecting?

Do you want some widgets that are only enabled when we have a read-only
document?

Hmmm... okay maybe this is the shared management problem again.  If I can
get this RBG [RadioButtonGroup] patch working we should be able to define
a RBG then toggle different radio buttons to get different sets of widgets
activated/deactivated.

Then I can generalize the patch to only use a set of ints rather than a
whole RBG (hh maybe I should do this now it might make it easier to
get working).  That'd allow you to define within your dialog an enum to
define the sets of widgets that can be activated together and inform the
BC when the enum state changes. bc().refresh() then activates the
appropriate widgets -- the dialog just has to track which set should be
active.  Hmmm yeah I think that'd probably be easier to implement than the
RBG specific thing I put on ice months ago.

Allan. (ARRae)

Re: MVC comments

[Allan Rae]

On Tue, 3 Apr 2001, Angus Leeming wrote:

  Angus,  I know you were going to reimplement the input checking functions
  of the dialogs to return an SMInput but this doesn't seem to have been
  done yet.

 E. Yes it has. Look at FormBase::InputCB rather than
 FormBaseDeprecated::inputCB. There's a reason for it being Deprecated...

Hmm... Well I had just 'grep valid *.[hC] | less' in xforms/ and saw a
bunch of calls to bc().valid() and thought that you must not have done it
yet.   It turns out it was another problem you were working around
instead.

 Yes, this is a fudge to a lacking ButtonPolicy. Consider inputting a
 citation-inset from the minibuffer. The params are perfectly valid, the
 dialog pops up. Do you want to "Apply" them? Yes I do!

Doesn't the citation inset already exist at that stage with those values?
You're more familiar with this process than I am since you reworked a lot
of it.

I think this is the problem we've discussed before about the
OkApplyCancel[ReadOnly]Policy.  I think it would probably make sense to:

-   outputs_[INITIAL] = CLOSE;
+   outputs_[INITIAL] = OKAY | APPLY | CLOSE;

This should be a safe change for both these policies.  It'd also mean that
after a Restore you can still press Okay or Apply without changing
something in the dialog.

Provided we do an input check on the contents of the dialog just as it is
being shown then we can move to the appropriate state (INVALID or
RO_INVALID) if the contents aren't initially valid.  I suspect we assume
that the contents are always valid on initial showing.

  John,  don't change the valid() function name or add another one.  Wait
  for Angus or I to change the operation of the dialogs input checking.
  Then you won't need those direct calls to bc().valid() just to workaround
  a mishandled input routine.

 I'd enjoy having you around again...

I'd enjoy being back.  I'll have to get familiar with the code again
though.  So much has changed.  You blokes, and you in particular Angus,
have been doing a terrific job.

Allan. (ARRae)

Re: MVC comments

[Allan Rae]

On Wed, 4 Apr 2001, Angus Leeming wrote:

 No, your right. But the thing isn't sophisticated enough to deal with it yet.
 Allan has been muttering that he's got some improvements up his sleeve.

I have to get them compiling first,  and then I can try to transfer them
to the new scheme and get them working again.  The improvements I have
only affects RadioButtionGroups.  It effectively allows groups of widgets
(buttons, inputs etc.) to be controlled by radio-buttons but still obey
the read-only disabling of the button controller.  More of a problem of
the button controller re-enabling things that should still be disabled.
I got started on this to get Paragraph working properly.

As for the problem at hand whatever_dialog.input() is meant to be the main
interface to directing the button controller.  If there are widgets you
don't want disabled when a document is read-only don't register it.  It
might however be handy to expose an iterator for the read-only list so the
list can be adjusted without having to do a complete rebuild of it.

I can certainly see that a callback for a dialog specific extension to the
buttoncontroller could be very handy for some fancy dialogs.  This
callback should probably only handle stuff that the BC doesn't handle.
That is, it shouldn't touch anything that is already handled by the BC --
like registered read-only widgets and the R-O-A-C buttons.  Otherwise you
should have written a dialog specific policy instead (or at least a
general one better suited to what you need).

##

A couple of things I noticed while taking a brief look at the sources:

ButtonController.h:69

template class Button, class Widget
void GuiBCButton, Widget::refresh()
{
if (okay_) {
-   bool const enabled = bp().buttonStatus(ButtonPolicy::OKAY);
-   setButtonEnabled(okay_, enabled);
+   setButtonEnabled(okay_,
+bp().buttonStatus(ButtonPolicy::OKAY);

saves the use of a named variable.  Likewise in 3 other places in
this function.


ButtonPolices.h:141
/// the dialog contents are read-only
SMI_READ_ONLY,
/// the dialog contents can be modified
SMI_READ_WRITE,

The policies are all designed so that you can continue modifying the
dialogs content if the _document_ is read-only.  However, the ReadOnly
policies disable the Okay and Apply buttons until the document becomes
read-writeable again.  Any widgets registered as read-only widgets will be
disabled but there is no requirement that you register any widgets.  That
is a matter of interface design, or "feel", not one of necessity.

Maybe the above paragraph should be merged into the existing source
documentation.

I should hurry up and draw those policy state machine diagrams and that
can start the new GUII documentation.

Allan. (ARRae)

Re: MVC comments

[Bill Wendling]

Also sprach Allan Rae:
} On Wed, 4 Apr 2001, Angus Leeming wrote:
} 
}  No, your right. But the thing isn't sophisticated enough to deal with it yet.
}  Allan has been muttering that he's got some improvements up his sleeve.
} 
} I have to get them compiling first,  and then I can try to transfer them
} to the new scheme and get them working again.  The improvements I have
} only affects RadioButtionGroups.  It effectively allows groups of widgets
} (buttons, inputs etc.) to be controlled by radio-buttons but still obey
} the read-only disabling of the button controller.  More of a problem of
} the button controller re-enabling things that should still be disabled.
} I got started on this to get Paragraph working properly.
} 
} As for the problem at hand whatever_dialog.input() is meant to be the main
} interface to directing the button controller.  If there are widgets you
} don't want disabled when a document is read-only don't register it.  It
} might however be handy to expose an iterator for the read-only list so the
} list can be adjusted without having to do a complete rebuild of it.
} 
} I can certainly see that a callback for a dialog specific extension to the
} buttoncontroller could be very handy for some fancy dialogs.  This
} callback should probably only handle stuff that the BC doesn't handle.
} That is, it shouldn't touch anything that is already handled by the BC --
} like registered read-only widgets and the R-O-A-C buttons.  Otherwise you
} should have written a dialog specific policy instead (or at least a
} general one better suited to what you need).
} 
} ##
} 
} A couple of things I noticed while taking a brief look at the sources:
} 
} ButtonController.h:69
} 
} template class Button, class Widget
} void GuiBCButton, Widget::refresh()
} {
} if (okay_) {
} -   bool const enabled = bp().buttonStatus(ButtonPolicy::OKAY);
} - setButtonEnabled(okay_, enabled);
} + setButtonEnabled(okay_,
} +  bp().buttonStatus(ButtonPolicy::OKAY);
 ^^
You missed a ')'.

-- 
|| Bill Wendling[EMAIL PROTECTED]

Re: MVC comments

[Angus Leeming]

No, your right. But the thing isn't sophisticated enough to deal with it yet. 
Allan has been muttering that he's got some improvements up his sleeve. 
So, as a work around...
Alternatively, if you would like an intellectual challenge...

A

On Wednesday 04 April 2001 15:06,  John Levon wrote:
 On Tue, 3 Apr 2001, Angus Leeming wrote:
 
  I think that this is exactly what Kalle was talking about this morning, 
no?
  
  Why not just not pass this operation though the (button) controller at 
all. 
  Ie, this is a manipulation rather than an input. The Apply/Ok buttons 
  will not change state, so cheat because the ButtonController isn't really 
  sophisticated enough to deal with this case cleanly.
 
 actually, you're probably right for this case, since they can't be 
activated in
 a read-only situation. Good point. Although I would humbly suggest special 
casing
 things like this is a bit ugly. And what happens if we have a button that 
can be
 used in read-only state, and can modify the dialog contents (but obviously 
not the 
 STATE of the contents) ? I can't think of a case yet, but ...
 
 I'm prolly missing something here ...
 
 john

Re: MVC comments

[Allan Rae]

On Tue, 3 Apr 2001, Angus Leeming wrote:

> > Angus,  I know you were going to reimplement the input checking functions
> > of the dialogs to return an SMInput but this doesn't seem to have been
> > done yet.
>
> E. Yes it has. Look at FormBase::InputCB rather than
> FormBaseDeprecated::inputCB. There's a reason for it being Deprecated...

Hmm... Well I had just 'grep valid *.[hC] | less' in xforms/ and saw a
bunch of calls to bc().valid() and thought that you must not have done it
yet.   It turns out it was another problem you were working around
instead.

> Yes, this is a fudge to a lacking ButtonPolicy. Consider inputting a
> citation-inset from the minibuffer. The params are perfectly valid, the
> dialog pops up. Do you want to "Apply" them? Yes I do!

Doesn't the citation inset already exist at that stage with those values?
You're more familiar with this process than I am since you reworked a lot
of it.

I think this is the problem we've discussed before about the
OkApplyCancel[ReadOnly]Policy.  I think it would probably make sense to:

-   outputs_[INITIAL] = CLOSE;
+   outputs_[INITIAL] = OKAY | APPLY | CLOSE;

This should be a safe change for both these policies.  It'd also mean that
after a Restore you can still press Okay or Apply without changing
something in the dialog.

Provided we do an input check on the contents of the dialog just as it is
being shown then we can move to the appropriate state (INVALID or
RO_INVALID) if the contents aren't initially valid.  I suspect we assume
that the contents are always valid on initial showing.

> > John,  don't change the valid() function name or add another one.  Wait
> > for Angus or I to change the operation of the dialogs input checking.
> > Then you won't need those direct calls to bc().valid() just to workaround
> > a mishandled input routine.
>
> I'd enjoy having you around again...

I'd enjoy being back.  I'll have to get familiar with the code again
though.  So much has changed.  You blokes, and you in particular Angus,
have been doing a terrific job.

Allan. (ARRae)

Re: MVC comments

[Allan Rae]

On Wed, 4 Apr 2001, Angus Leeming wrote:

> No, your right. But the thing isn't sophisticated enough to deal with it yet.
> Allan has been muttering that he's got some improvements up his sleeve.

I have to get them compiling first,  and then I can try to transfer them
to the new scheme and get them working again.  The improvements I have
only affects RadioButtionGroups.  It effectively allows groups of widgets
(buttons, inputs etc.) to be controlled by radio-buttons but still obey
the read-only disabling of the button controller.  More of a problem of
the button controller re-enabling things that should still be disabled.
I got started on this to get Paragraph working properly.

As for the problem at hand whatever_dialog.input() is meant to be the main
interface to directing the button controller.  If there are widgets you
don't want disabled when a document is read-only don't register it.  It
might however be handy to expose an iterator for the read-only list so the
list can be adjusted without having to do a complete rebuild of it.

I can certainly see that a callback for a dialog specific extension to the
buttoncontroller could be very handy for some fancy dialogs.  This
callback should probably only handle stuff that the BC doesn't handle.
That is, it shouldn't touch anything that is already handled by the BC --
like registered read-only widgets and the R-O-A-C buttons.  Otherwise you
should have written a dialog specific policy instead (or at least a
general one better suited to what you need).

##

A couple of things I noticed while taking a brief look at the sources:

ButtonController.h:69

template 
void GuiBC::refresh()
{
if (okay_) {
-   bool const enabled = bp().buttonStatus(ButtonPolicy::OKAY);
-   setButtonEnabled(okay_, enabled);
+   setButtonEnabled(okay_,
+bp().buttonStatus(ButtonPolicy::OKAY);

saves the use of a named variable.  Likewise in 3 other places in
this function.


ButtonPolices.h:141
/// the dialog contents are read-only
SMI_READ_ONLY,
/// the dialog contents can be modified
SMI_READ_WRITE,

The policies are all designed so that you can continue modifying the
dialogs content if the _document_ is read-only.  However, the ReadOnly
policies disable the Okay and Apply buttons until the document becomes
read-writeable again.  Any widgets registered as read-only widgets will be
disabled but there is no requirement that you register any widgets.  That
is a matter of interface design, or "feel", not one of necessity.

Maybe the above paragraph should be merged into the existing source
documentation.

I should hurry up and draw those policy state machine diagrams and that
can start the new GUII documentation.

Allan. (ARRae)

Re: MVC comments

[Bill Wendling]

Also sprach Allan Rae:
} On Wed, 4 Apr 2001, Angus Leeming wrote:
} 
} > No, your right. But the thing isn't sophisticated enough to deal with it yet.
} > Allan has been muttering that he's got some improvements up his sleeve.
} 
} I have to get them compiling first,  and then I can try to transfer them
} to the new scheme and get them working again.  The improvements I have
} only affects RadioButtionGroups.  It effectively allows groups of widgets
} (buttons, inputs etc.) to be controlled by radio-buttons but still obey
} the read-only disabling of the button controller.  More of a problem of
} the button controller re-enabling things that should still be disabled.
} I got started on this to get Paragraph working properly.
} 
} As for the problem at hand whatever_dialog.input() is meant to be the main
} interface to directing the button controller.  If there are widgets you
} don't want disabled when a document is read-only don't register it.  It
} might however be handy to expose an iterator for the read-only list so the
} list can be adjusted without having to do a complete rebuild of it.
} 
} I can certainly see that a callback for a dialog specific extension to the
} buttoncontroller could be very handy for some fancy dialogs.  This
} callback should probably only handle stuff that the BC doesn't handle.
} That is, it shouldn't touch anything that is already handled by the BC --
} like registered read-only widgets and the R-O-A-C buttons.  Otherwise you
} should have written a dialog specific policy instead (or at least a
} general one better suited to what you need).
} 
} ##
} 
} A couple of things I noticed while taking a brief look at the sources:
} 
} ButtonController.h:69
} 
} template 
} void GuiBC::refresh()
} {
} if (okay_) {
} -   bool const enabled = bp().buttonStatus(ButtonPolicy::OKAY);
} - setButtonEnabled(okay_, enabled);
} + setButtonEnabled(okay_,
} +  bp().buttonStatus(ButtonPolicy::OKAY);
 ^^
You missed a ')'.

-- 
|| Bill Wendling[EMAIL PROTECTED]

Re: MVC comments

[Angus Leeming]

No, your right. But the thing isn't sophisticated enough to deal with it yet. 
Allan has been muttering that he's got some improvements up his sleeve. 
So, as a work around...
Alternatively, if you would like an intellectual challenge...

A

On Wednesday 04 April 2001 15:06,  John Levon wrote:
> On Tue, 3 Apr 2001, Angus Leeming wrote:
> 
> > I think that this is exactly what Kalle was talking about this morning, 
no?
> > 
> > Why not just not pass this operation though the (button) controller at 
all. 
> > Ie, this is a "manipulation" rather than an "input". The Apply/Ok buttons 
> > will not change state, so cheat because the ButtonController isn't really 
> > sophisticated enough to deal with this case cleanly.
> 
> actually, you're probably right for this case, since they can't be 
activated in
> a read-only situation. Good point. Although I would humbly suggest special 
casing
> things like this is a bit ugly. And what happens if we have a button that 
can be
> used in read-only state, and can modify the dialog contents (but obviously 
not the 
> STATE of the contents) ? I can't think of a case yet, but ...
> 
> I'm prolly missing something here ...
> 
> john

Re: MVC comments

[John Levon]

On Tue, 3 Apr 2001, Allan Rae wrote:

 John,  don't change the valid() function name or add another one.  Wait
 for Angus or I to change the operation of the dialogs input checking.
 Then you won't need those direct calls to bc().valid() just to workaround
 a mishandled input routine.
 
 Allan. (ARRae)

OK, I actually realised last night I was misunderstanding what I wanted.

I actually have another problem/request: we need to share management of buttons
between the controller and the dialog.

for exapmle, the citation dialog has "Add" "Remove" buttons which obviously should be
disabled when readonly etc. Unfortunately the dialog also has some say in when they
should be enabled. Currently in the kde frontend (well when I commit) I am doing, 
essentially :

bc().valid(form_-add(bla...));
form_-updateButton();

after every bc().operation.

What do you think of the possibility of registering a callback method of some kind
that would be called after doing the standard enable/disable of the controller ?

Hmm, I haven't explained that very well, I hope you swim

btw, Angus, am I ok to change the TabCreate controller to access setParams(uint, uint)
? The dialogs have no business knowing that the rows, cols are represented as "rows 
cols"
string in the Dispatch

thanks
john

-- 
"Unredeemable train-spotting vacuity overlaid by the gloss of management theory."
- John Redwood on William "Tory Boy" Haigh

Re: MVC comments

[Angus Leeming]

 btw, Angus, am I ok to change the TabCreate controller to access 
setParams(uint, uint)
 ? The dialogs have no business knowing that the rows, cols are represented 
as "rows cols"
 string in the Dispatch

Of course.
A

Re: MVC comments

[Angus Leeming]

 I actually have another problem/request: we need to share management of 
buttons
 between the controller and the dialog.
 
 for exapmle, the citation dialog has "Add" "Remove" buttons which obviously 
should be
 disabled when readonly etc. Unfortunately the dialog also has some say in 
when they
 should be enabled. Currently in the kde frontend (well when I commit) I am 
doing, essentially :
 
   bc().valid(form_-add(bla...));
   form_-updateButton();
 
 after every bc().operation.

I think that this is exactly what Kalle was talking about this morning, no?

Why not just not pass this operation though the (button) controller at all. 
Ie, this is a "manipulation" rather than an "input". The Apply/Ok buttons 
will not change state, so cheat because the ButtonController isn't really 
sophisticated enough to deal with this case cleanly.

A.

Re: MVC comments

[John Levon]

On Tue, 3 Apr 2001, Allan Rae wrote:

> John,  don't change the valid() function name or add another one.  Wait
> for Angus or I to change the operation of the dialogs input checking.
> Then you won't need those direct calls to bc().valid() just to workaround
> a mishandled input routine.
> 
> Allan. (ARRae)

OK, I actually realised last night I was misunderstanding what I wanted.

I actually have another problem/request: we need to share management of buttons
between the controller and the dialog.

for exapmle, the citation dialog has "Add" "Remove" buttons which obviously should be
disabled when readonly etc. Unfortunately the dialog also has some say in when they
should be enabled. Currently in the kde frontend (well when I commit) I am doing, 
essentially :

bc().valid(form_->add(bla...));
form_->updateButton();

after every bc().operation.

What do you think of the possibility of registering a callback method of some kind
that would be called after doing the standard enable/disable of the controller ?

Hmm, I haven't explained that very well, I hope you swim

btw, Angus, am I ok to change the TabCreate controller to access setParams(uint, uint)
? The dialogs have no business knowing that the rows, cols are represented as "rows 
cols"
string in the Dispatch

thanks
john

-- 
"Unredeemable train-spotting vacuity overlaid by the gloss of management theory."
- John Redwood on William "Tory Boy" Haigh

Re: MVC comments

[Angus Leeming]

> btw, Angus, am I ok to change the TabCreate controller to access 
setParams(uint, uint)
> ? The dialogs have no business knowing that the rows, cols are represented 
as "rows cols"
> string in the Dispatch

Of course.
A

Re: MVC comments

[Angus Leeming]

> I actually have another problem/request: we need to share management of 
buttons
> between the controller and the dialog.
> 
> for exapmle, the citation dialog has "Add" "Remove" buttons which obviously 
should be
> disabled when readonly etc. Unfortunately the dialog also has some say in 
when they
> should be enabled. Currently in the kde frontend (well when I commit) I am 
doing, essentially :
> 
>   bc().valid(form_->add(bla...));
>   form_->updateButton();
> 
> after every bc().operation.

I think that this is exactly what Kalle was talking about this morning, no?

Why not just not pass this operation though the (button) controller at all. 
Ie, this is a "manipulation" rather than an "input". The Apply/Ok buttons 
will not change state, so cheat because the ButtonController isn't really 
sophisticated enough to deal with this case cleanly.

A.

Re: MVC comments

[John Levon]

On Mon, 2 Apr 2001, John Levon wrote:

 3) Segfault: worryingly this might be a kernel thing. If you do tabcreate-OK, then 
tabcreate-OK
 again, *boom* :/

I can't reproduce this one today ...

john

-- 
"You see things; and you say `Why?'  But I dream things that never
were; and I say `Why not?'"
- George Bernard Shaw

Re: MVC comments

[Angus Leeming]

On Monday 02 April 2001 14:12, John Levon wrote:
 I'm about to commit a patch to update the KDE frontend
 to MVC for everything, whilst doing it I came across some things :
 
 1) Warning :
 - , okay_(0), apply_(0), cancel_(0), undo_all_(0)
 + , okay_(0), apply_(0), undo_all_(0), cancel_(0)

Fixed in my source.

 2) Can we possibly rename the "UndoAll" stuff to "Restore" ? 
 After all, that's what the button is called, and also better reflects
  the associated action IMHO

Sure.

 4) the VCLog controller is all wrong, the getLogFile method 
 actually creates a log file via the VC commands. This *must*
  be done only at the time the dialog is opened (each time)
 and also, we need to unlink the file once the dialog has been populated.

Patch please ;-)

 5) Angus, is there a good reason why FormBase for xforms doesn't 
 have bc().refresh() in its show() function ? Currently you have
 bc().refresh() in each build() method for every dialog ...

No reason. Will do. Thank you for pointing this out.

 6) is there any chance we can rename ControlButton - ControlButtons ?
 I don't have a very good reason for this, but Qt kindly has "ControlButton"
 as a global enum value. It's getting really difficult to order the headers
  in kde/ correctly to avoid this braindamage, so this would  make things
  a lot easier on me ... I know this isn't a very good reason for a change,
  but I can't see it would cause harm either

Will do. What a nice guy I am!

 7) I find it a bit weird that I call a method "valid(bool)" whenever 
 e.g. a user types another character in a line edit widget. Can we 
 add another method mutated(bool) or changed(bool) possibly ?
 This would make at least the KDE frontend code a lot clearer IMHO

The name reflects the original function. The function has changed, so why not 
the name.

Why don't you submit a patch for all this? I'm a bit busy this week.

A

Re: MVC comments

[John Levon]

On Mon, 2 Apr 2001, Angus Leeming wrote:

 Why don't you submit a patch for all this? I'm a bit busy this week.

I will, thought it best to run by you ;)

thanks
john

-- 
"You see things; and you say `Why?'  But I dream things that never
were; and I say `Why not?'"
- George Bernard Shaw

Re: MVC comments

[Allan Rae]

On Mon, 2 Apr 2001, Angus Leeming wrote:
  7) I find it a bit weird that I call a method "valid(bool)" whenever
  e.g. a user types another character in a line edit widget. Can we
  add another method mutated(bool) or changed(bool) possibly ?
  This would make at least the KDE frontend code a lot clearer IMHO

There's more than simply "changed/unchanged".  valid() should only be
called when a change has happened.  So it represents "valid
changed/invalid changed".   You are also free to call bc.input(SMInput)
directly.

 The name reflects the original function. The function has changed, so why not
 the name.

If the function has changed so that it no longer means "that was a valid
input from the user" then I hope you also made appropriate changes to the
state machines because they are all defined based on the definition that
SMI_VALID represents a valid user input.

From the quick look I just had at ButtonPolices.[hC] and
ButtonControllerBase.[hC] it seems that bc.valid() still means that the
user just entered a valid input.  I didn't think you had changed this.

Angus,  I know you were going to reimplement the input checking functions
of the dialogs to return an SMInput but this doesn't seem to have been
done yet.

[long pause]

Okay I think I see what John is complaining about now: all those direct
calls to bc_.valid() in an effort to force the OK button to be available
all because the input checking doesn't return true when it should.  That
was what the change in the dialog.input() checking was supposed to fix.

John,  don't change the valid() function name or add another one.  Wait
for Angus or I to change the operation of the dialogs input checking.
Then you won't need those direct calls to bc().valid() just to workaround
a mishandled input routine.

Allan. (ARRae)

Re: MVC comments

[John Levon]

On Mon, 2 Apr 2001, John Levon wrote:

> 3) Segfault: worryingly this might be a kernel thing. If you do tabcreate->OK, then 
>tabcreate->OK
> again, *boom* :/

I can't reproduce this one today ...

john

-- 
"You see things; and you say `Why?'  But I dream things that never
were; and I say `Why not?'"
- George Bernard Shaw

Re: MVC comments

[Angus Leeming]

On Monday 02 April 2001 14:12, John Levon wrote:
> I'm about to commit a patch to update the KDE frontend
> to MVC for everything, whilst doing it I came across some things :
> 
> 1) Warning :
> - , okay_(0), apply_(0), cancel_(0), undo_all_(0)
> + , okay_(0), apply_(0), undo_all_(0), cancel_(0)

Fixed in my source.

> 2) Can we possibly rename the "UndoAll" stuff to "Restore" ? 
> After all, that's what the button is called, and also better reflects
>  the associated action IMHO

Sure.

> 4) the VCLog controller is all wrong, the getLogFile method 
> actually creates a log file via the VC commands. This *must*
>  be done only at the time the dialog is opened (each time)
> and also, we need to unlink the file once the dialog has been populated.

Patch please ;-)

> 5) Angus, is there a good reason why FormBase for xforms doesn't 
> have bc().refresh() in its show() function ? Currently you have
> bc().refresh() in each build() method for every dialog ...

No reason. Will do. Thank you for pointing this out.

> 6) is there any chance we can rename ControlButton -> ControlButtons ?
> I don't have a very good reason for this, but Qt kindly has "ControlButton"
> as a global enum value. It's getting really difficult to order the headers
>  in kde/ correctly to avoid this braindamage, so this would  make things
>  a lot easier on me ... I know this isn't a very good reason for a change,
>  but I can't see it would cause harm either

Will do. What a nice guy I am!

> 7) I find it a bit weird that I call a method "valid(bool)" whenever 
> e.g. a user types another character in a line edit widget. Can we 
> add another method mutated(bool) or changed(bool) possibly ?
> This would make at least the KDE frontend code a lot clearer IMHO

The name reflects the original function. The function has changed, so why not 
the name.

Why don't you submit a patch for all this? I'm a bit busy this week.

A

Re: MVC comments

[John Levon]

On Mon, 2 Apr 2001, Angus Leeming wrote:

> Why don't you submit a patch for all this? I'm a bit busy this week.

I will, thought it best to run by you ;)

thanks
john

-- 
"You see things; and you say `Why?'  But I dream things that never
were; and I say `Why not?'"
- George Bernard Shaw

Re: MVC comments

[Allan Rae]

On Mon, 2 Apr 2001, Angus Leeming wrote:
> > 7) I find it a bit weird that I call a method "valid(bool)" whenever
> > e.g. a user types another character in a line edit widget. Can we
> > add another method mutated(bool) or changed(bool) possibly ?
> > This would make at least the KDE frontend code a lot clearer IMHO

There's more than simply "changed/unchanged".  valid() should only be
called when a change has happened.  So it represents "valid
changed/invalid changed".   You are also free to call bc.input(SMInput)
directly.

> The name reflects the original function. The function has changed, so why not
> the name.

If the function has changed so that it no longer means "that was a valid
input from the user" then I hope you also made appropriate changes to the
state machines because they are all defined based on the definition that
SMI_VALID represents a valid user input.

>From the quick look I just had at ButtonPolices.[hC] and
ButtonControllerBase.[hC] it seems that bc.valid() still means that the
user just entered a valid input.  I didn't think you had changed this.

Angus,  I know you were going to reimplement the input checking functions
of the dialogs to return an SMInput but this doesn't seem to have been
done yet.

[long pause]

Okay I think I see what John is complaining about now: all those direct
calls to bc_.valid() in an effort to force the OK button to be available
all because the input checking doesn't return true when it should.  That
was what the change in the dialog.input() checking was supposed to fix.

John,  don't change the valid() function name or add another one.  Wait
for Angus or I to change the operation of the dialogs input checking.
Then you won't need those direct calls to bc().valid() just to workaround
a mishandled input routine.

Allan. (ARRae)