On Friday 17 May 2002 6:18 am, Allan Rae wrote: > On Thu, 16 May 2002, Angus Leeming wrote: > > On Thursday 16 May 2002 6:20 am, Allan Rae wrote: > > [...] > > > > Allan. (ARRae) > > > > Why don't you read the bloody code before talking a pile of crap? > > Not all the pile was crap but after reading the code I now see that > some of it might have been. > > > There are no callbacks, only signals. There is no input, only multiple > > slots. > > If the various inputs are all tested in their respective slots (surely > some of them can be invalid even for the code you have already changed > -- rather than just returning without telling the BC that you found > something invalid) and the complex widgets also tell the BC when a > valid input was found (it'd be nice if they too declared invalid > inputs instead of silently returning from the slot function) then the > BC should already be in an appropriate state.
No! Set some widget to an invalid state. Set some other widget to a valid state. The button controller is now valid (crap!). We HAVE to check all widgets that MIGHT be invalid every time we call the button controler. > At worst you only have relationships between widgets to check -- not > widgets that form a super-widget as these are already taken care of by > your slots. The widget-dependency/relationship testing should > argueably be on a per-frontend basis since the widgets are frontend > specific and as John pointed out different frontends might implement > stuff in different ways. And this widget-dependency stuff is what > the input() callback was originally meant to do (along with per-widget > testing that you have now moved into slots). I think that I haven't returned INVALID from any of these slots because none of the widgets I've encountered yet can have an invalid state. A LyxGlueLengthWidget could, for example, but I haven't had to use it yet. Of course, I may have missed some. We can get rid of NOOP using this approach too... Anyway, that brings me on to the flaw in your design and why a list of suspect widgets is a Good Thing. With your design I have to check all such widgets in Input (or slot or whatever) to determine the VALID/INVALID parameter passed to the button controller. That doesn't sit nicely with the concepts of one slot one widget. Even with Input it's a pain. Adding an addSuspect to the button controller, analogous to your addReadOnly method resolves the problem with no effort at all. And it's as easy to implement as the existing addReadOnly. Moreover, if you don't want it, don't use it. I don't see the problem. Remember, only a very few inputs can possibly be invalid, so it's not a large list to loop over. > The code does look pretty but I wonder how much polishing is too much. > > Have you measured code size and compile speed changes with this new > approach? In this case it seems to have no discernible effect on responsiveness. Remember that human interaction is the slow part of graphical interaction. The advantage is that it makes the logic transparent; always good for bug squashing. Angus
