On Wed, 18 Apr 2001, John Levon wrote:
> On Tue, 17 Apr 2001, Allan Rae wrote:
[...]
> > Gotta put all those configuration items somewhere the screen isn't big
> > enough for one dialog and having multiple dialogs that you blaze a trail
> > through like W2k networking config is a bigger pain than
On Tue, 17 Apr 2001, Allan Rae wrote:
> Sure. Not everyone reads the "This buffer is readonly -- you can't change
> stuff" dialog. But you are right though.
I'm not sure what you're referring to here ? Sorry, I am forgetful.
> > FWIW, the KDE frontend was managing just fine without an explici
On Fri, 13 Apr 2001, John Levon wrote:
> On Thu, 12 Apr 2001, Allan Rae wrote:
>
> > I have been. Trouble is other people want to do more with it than I
> > originally meant it for. In particular people want to disable entries for
> > read-only documents when AFAIAC this is unnecessary because
On Sat, 14 Apr 2001, Asger K. Alstrup Nielsen wrote:
[...]
> In other words, maybe we indeed have discovered a good point to draw a
> line in the sand: As long as a controller abstracts both across different
> dialogs within the same toolkit, and across different toolkits, it
> probably is a good
On Thu, 12 Apr 2001, Allan Rae wrote:
> > I think you should consider once more whether this big and complicated
> > machinery is really the best approach.
>
> I have been. Trouble is other people want to do more with it than I
> originally meant it for.
And this will be the situation for a lo
On Thu, 12 Apr 2001, Allan Rae wrote:
> I have been. Trouble is other people want to do more with it than I
> originally meant it for. In particular people want to disable entries for
> read-only documents when AFAIAC this is unnecessary because the OK and
> Apply buttons are disabled in those
On Thu, Apr 12, 2001 at 04:37:00PM +1000, Allan Rae wrote:
> [snip]
>
> Well I went for a walk to the bookshop and browsed through some C++ texts
> there and discovered a mind-blowing book called:
>
> "Modern C++ Design: Generic Programming and Design Patterns Applied"
> Andrei Alexandrescu
> Ad
On Thu, 12 Apr 2001, Allan Rae wrote:
> On Wed, 11 Apr 2001, Asger K. Alstrup Nielsen wrote:
>
> > > Thoughts?
> >
> > I think you should consider once more whether this big and complicated
> > machinery is really the best approach.
>
> I have been. Trouble is other people want to do more with i
On Tue, 10 Apr 2001, Angus Leeming wrote:
> Allan,
> you must be in line for the prize for longest emails in history! I think
> we're getting to the point where we really should write some formal
> documentation for the GUI stuff again.
That's what I'm doing in these long emails. Then I can com
On Wed, 11 Apr 2001, Asger K. Alstrup Nielsen wrote:
> > Thoughts?
>
> I think you should consider once more whether this big and complicated
> machinery is really the best approach.
I have been. Trouble is other people want to do more with it than I
originally meant it for. In particular peop
On Wed, 11 Apr 2001, Asger K. Alstrup Nielsen wrote:
> extend even this general mechanism fairly soon. Then, you will discover
> that some dialog should enable and disable buttons according to what a
> certain input field contains, what item is selected in a drop list,
> and so on.
We've *alread
Morning, Asger.
Given, Allan's relatively low coding input at the moment to the mainstream
humdrum of GUII, I'd say let's keep him happy and encourage him to do
this! Most of the dialogs already have a controller-view split and the
non-xforms GUIs have clearly benefitted from this. However, th
> Thoughts?
I think you should consider once more whether this big and complicated
machinery is really the best approach.
It seems to be, looking from the sideline, that you have come to this
point like this: First, an initial buttoncontroller was build. This
turned out to be not as general as
Allan,
you must be in line for the prize for longest emails in history! I think
we're getting to the point where we really should write some formal
documentation for the GUI stuff again.
It'll take a while to digest, but the basic idea is very powerful. And it
appears that changes in classes u
On Tue, 10 Apr 2001, Allan Rae wrote:
> 2. Ideally I'd like to derive new policies from existing ones but how will
>that affect the SMInput and State enums we currently use. Can we
>simply overload the enums and expect everything to work?
> 2a. I really don't want to have to add eve
Or will it be Mark IV?
[... I almost finished writing what I'd thought of last night when a
better idea occured to me. Rather than lose/rewrite what I'd written I've
left it in here and Mark V can be found in the P.S. at the end ;-)
Some of the discussion on Mark IV is still relevent however ...
16 matches
Mail list logo
