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.
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
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
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
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
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.
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
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
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
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
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
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 ?
>
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.
>
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
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
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
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.
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
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.
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
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
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:
> > 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
>
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
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
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, 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.
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
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
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.
>
>
> 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
> 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
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
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),
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
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
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
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),
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
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
40 matches
Mail list logo
