Re: MVC comments
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
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
On 05-Apr-2001 Angus Leeming wrote: > 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? Well we don't want to update the paragraph-layout when we change paragraph otherwise we are not able to apply the same changes to different paragraphs, isn't it? So the update in the paragraph-layout should not be automatically only the activation of the OK/Apply buttons should automatized (if the params inside the dialog != of the params of the stuff the dialog should change) So we need some way to "force" the update of the dialog. Got me ;) 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ It was all so different before everything changed.
Re: MVC comments
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
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 cre
Re: MVC comments
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
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
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
On Thursday 05 April 2001 07:31, Allan Rae wrote: > 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. 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. Just a thought. Angus
Re: MVC comments
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
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
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
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
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
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
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 -- "Creating laws which cannot be universally enforced leads to arbitrary enforcement." - Upsilon, /.
Re: MVC comments
> 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
> 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
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
My apologies; I was getting confused. I don't actually use ButtonController::valid(bool) to change the state of the buttons anymore. FormBase::InputCB calls ButtonController::input direct. > 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... All dialogs that have been ported to the controller-view split are derived from FormBase, not FormBaseDeprecated. > > 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. 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! > 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... Angus
Re: MVC comments
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
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
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
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
MVC comments
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 : diff -u -r1.3 ButtonController.h --- src/frontends/controllers/ButtonController.h2001/03/30 16:42:54 1.3 +++ src/frontends/controllers/ButtonController.h2001/03/30 19:46:52 @@ -62,7 +62,7 @@ template GuiBC::GuiBC(string const & cancel, string const & close) : ButtonControllerBase(cancel, close) - , okay_(0), apply_(0), cancel_(0), undo_all_(0) + , okay_(0), apply_(0), undo_all_(0), cancel_(0) {} 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 3) Segfault: worryingly this might be a kernel thing. If you do tabcreate->OK, then tabcreate->OK again, *boom* :/ 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. 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 ... 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 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 thanks john -- "You see things; and you say `Why?' But I dream things that never were; and I say `Why not?'" - George Bernard Shaw