On Wed, 22 Sep 1999, Mirko Sucker wrote:
> Espen Sand wrote:
> 
> > I have been working on making the DialogCore compatible (using the same
> > methods) with the current DialogBase.  When doing this I have copied much of
> > the code/ideas from DialogBase and added a number of improvements/features,
> 
> Some parts of it are rather tricky, arent they :-)
> 
> > The goal is to make a very easy to use dialog class that provides features
> > such as tabbed, and treelists type (and more) dialogs and that uses defined but
> > changable margins and spacings (provided by hint() methods) so that all dialogs
> > use the  same settings.
> 
> As I said in the other message you should get today, I want to opt for two
> different classes: the dialog base class creating a common design for KDE dialogs,
> and another class creating (at least) one common main part design. Derived design
> would make this well-structured.
> 
> > I have added a simple but powerful action button layout
> > mechanism that controls the button order (see below 6-8). The number of
> > predefined dialogs types (faces) can easily be extended later without breaking
> > old code.
> >
> > SO: What does it take to replace the current DialogBase with the new code?
> 
> If it is compatible: nothing (in my opinion). Just check it in at the place of
> dialogbase.
> 
> > I have not yet made documentation. I can copy/paste a lot from the current
> > DialogCore and add the new that is needed. Most of all I want to make a
> > tutorial with copy/paste examples with screenshots (based from khexedit)
> > that goes to developer.kde.org.
> 
> Some basic information should be included, I think.
> 
> > 1. Renamed to KDialogBase (just so that it can coexists with DialogBase for now)
> 
> Why not check it into kdeui? DialogBase is not holy ...
> 
> > 2. Does everything DialogBase currently do + much more.
> >
> > 3. I have installed it in my local kdeui lib and replaced the
> > instances of DialogBase with KDialogBase etc in the CVS. Everything (using
> > DialogBase) works as before as far as I can see!
> >
> > ... 7. The action buttons are as follows:
> > Help|Default|User3|User2|User|Ok|Apply|Cancel. "Cancel" can be replaced
> > by "Close" and "Apply" with "Try". All buttons use accelerators. The user
> > can decide the name of the "UserN" buttons. Buttons can be grayed out,
> > and/or hidden (should not be used much tough)
> >
> > 8. The user decides what buttons should be present, but do no decide in what
> > order. The order is defined by the style and can be controlled centrally.
> > I think this is a big advantage.
> >
> > 9. The standard caption is "captionText - <appName>". setCaption() has
> > been reimplemented to to do this automatically. There is a setPlainCaption()
> > that does things the std way.
> 
> This stuff (7-9) is complex, but useful. I agree that the buttons of DialogBase are
> not that flexible.
> Please add some docs, and think about the partening of dialog base class and dialog
> contents design, these are my points. Both could be included in dialogbase.{h,cpp}.
> 

Nay, 7-8 are easy to code and implement ;). As for 9, it is as you perhaps know
already in kapp (makeStdCaption()) so that is not a problem either ;)

Mirko, please take the time to read the "elephant" mail I just sent you. There
are new code attached to it. I hope this should make it even more versatile. I
really dont like to just replace a class in the cvs you have made unless you
agree it is ok.

To the other listeners: the code in question is already used by khexedit
v 0.8.4 in cvs (dialogcore and januswidget).


-- 
Espen Sand