[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Resizeable Dialogs, Layout & Co.
From:       Carsten Pfeiffer <carpdjih () cetus ! zrz ! TU-Berlin ! DE>
Date:       2001-01-04 14:08:40
[Download RAW message or body]

On Thu, Jan 04, 2001 at 01:18:17PM +0100, Friedrich W. H. Kossebau wrote:

Hi,
 
> So you do agree that this is a nice feature that should be a style
> advise, don't you? What about the others? And how could this be voted to
> be included in the official guide?

this is definitely advisable, because fixed widgets/dialogs break when
translations into other languages need more space than the hardcoded
widget-size. Waldo, could you add a few sentences about that?
 
> How could this be done? The kconfig data read of the config file is kept
> for the whole run time of a program I think. But dialogs are only
> temporary "alive". So they would have to read and write the size
> information directly before and after the dialogs popup. So all the
> programmer should need to do is to tell the dialog a pointer to the
> config data and a identifier name for the dialog. The rest like reading
> and writing the size data is done by the KDialogBase. 

Right. In most cases, it could even use the app-wide KConfig object 
(KGlobal::config()). You only need to have a unique identifier for each
dialog in an app. That could be the QObject::name() of the dialog. Not
everybody sets this name to something useful, but that could change.
 
> A flag should be setable whether to store the last size or not. To set
> standard size there is also the need of a call "takeThisAsStandardSize"
> or something which would tell the dialog the save the actual size as
> size to the config if no flag is set to use size of time of quitting the
> dialog.

This could be handled internally by KDialogBase, optionally configurable
of course. When KDialogBase closes, it checks if it should save the size and
the identifier (name()) is set and saves.
 
> Could this be added without breaking the binary compatibility? I don't
> have  a clue how librarys are constructed and in what adding new
> function calls to the interface results. Could someone tell me?

Yes, this would be possible.
 
> IIRC the dialog can be told where to place ( by telling parent window?).

Right.

> This is hardcoded. But I thought about if it would delight users if they
> could tell dialogs where to appear, so not to lay on the programmers
> will.

The parent is used to tell have the dialog centered above the parent's window,
which is quite nice IMHO.

> So it needs someone to do the work to integrate this into the
> controlcenter and to think about a way where to store this information
> and how make it accessible to KDialog (and others). Maybe it should be
> treated the way the information about the set font is treated. 
> 
> The module in the control center could be in the style of the color
> module to preview the look. Or the font, color and sizing could be
> integrated in one module as it would be nice to have a preview of all
> togheter. 

That would be the beginning of the job, I think. The bigger job would be
to make sure all dialogs really make use of that. I'm afraid there are
quite some dialogs that don't use KDialogBase yet.

Are you willing to have a look at that (the support in KDialogBase and
the control-module for a start)?

Best wishes
Carsten Pfeiffer

[prev in list] [next in list] [prev in thread] [next in thread]