Espen Sand wrote:

> Would you be very angry/refuse that DialogBase inherits CDialogCore in
> "CDialogCore::Plain" dialog layout mode? DialogBase could then be the easy to
> use version of DialogCore that most people (ie. dialogs) would actually need. I
> could modify CDialogCore so that DialogBase is a friend class to allow it to set
> the Action button text (altough I am not very happy with it ;-) as I have said
> earlier).

Hello Espen,
of course not.
We have to remember two arguments:

  1. You cannot take anything out of the user interface that is part of the library once.
     Be sure that we discussed a long time at Kaiserslautern before we added DialogBase and
     KAboutDialog to kdeui. Our idea was to add something as a starting point, and possibly
     find people like you to enhance it. The problem is only that you write another class
     that does the same - maybe better, but for the same reason. So it cannot be added to
     kdeui, as there is already one for this problem.
     So we MUST merge the classes. I like your ideas, and I know that DialogBase lacks some
     functions and that KAboutDialog is merely useable as a quick displaying dialog for
     small apps. It was never intended as the KDE about dialog.
     So, I will have a look at your current implementations, and then let us join the two
     classes. A friend-relationship will not solve the problem having two basic dialog
     classes in kdeui. Having two base classes for dialogs will not lead us to similar
     dialogs over all apps.
  2. It is not randomly decided to add only three buttons (OK, Accept, Cancel) to the
     dialogs core. The idea is:
     Only this three buttons have a meaning to the program outside of the dialog. Every
     other button only changes stuff inside the dialog. If you have a look at a
     DialogBase-derived dialog, you see the inner part clearly partened from the three
     buttons controlling the dialog window.
     With this idea in mind, your user buttons only make sense if they are used to manage
     functions similar to OK, Accept or Cancel. The Help button provides the same
     functionality as the help link in DialogBase dialogs, except that the help link is
     arranged top-left, where the help menu is located usually.
     So you see, the design of DialogBase is not randomly. That is why I proposed to
     implement your three standard dialog designs as stand alone widgets, and add it in the
     manner of the DialogBase main widget to the dialog. This way, all user button appear
     inside the inner part of the dialog, it is harder to get a stupid dialog layout :-)
     (Additionally, the widgets could be used outside of dialogs, what could lead to apps
     with more similar user interface).
     User buttons in the outer dialog frame may be added, but the docs need to point to
     VERY special cases where this buttons should be used (I currently can not imagine
     one). We could even put the declarations of this dialog design options in the
     dialogbase.h header file.

I hope this shows my opinion in a clear manner. We should prepend to fail in things we
already solved before.
Greetings,
--Mirko.
PS: I added a example program to the KDE 2.0 sources. It is located in kdelibs/kdetest and
is called dialogbasetest.

--
Denn der  Mensch  liebt und ehrt den  Menschen,  solange er ihn
nicht zu beurteilen vermag, und die Sehnsucht ist ein Erzeugnis
mangelhafter Erkenntnis. (Thomas Mann)