On Tue, 14 Mar 2006 13:54:14 +0200
"Yury Sidorov" <[EMAIL PROTECTED]> wrote:
> From: "Mattias Gaertner" <[EMAIL PROTECTED]>
> > On Tue, 14 Mar 2006 12:47:21 +0200
> > "Yury Sidorov" <[EMAIL PROTECTED]> wrote:
> >
> >> From: "Mattias Gaertner" <[EMAIL PROTECTED]>
> >> >> > AFAIK the form size and its content is not completely under
> >control > >of > > the LCL. So only the most simplest forms can be made
> >fixed size. > >>
> >> >> Sure. If resizing do nothing useful for particular dialog, there is
> >no > >> need to allow user to resize it.
> >> >
> >> > I'm not sure, you understood.
> >> > Especially if the resizing does nothing useful, the fixed size makes
> >> > trouble. For example your controls need a height of 200, but the
> >window > > manager only gives you a size of 190.
> >>
> >> Hmm, then user need to resize forms constantly by himself...
> >> How it can happen if I set client height of form to 200, but it
> >actually > set to 190?
> >
> > There are several problems.
> > Some window managers define the width and height including the border,
> > some
> > without, and there is no easy way to find out. It seems getting better,
> > so at least it works under the most common wm.
> > Then come the hen and the egg problem: To determine the needed
> > ClientHeight,
> > you need the theme and the font size, which needs the Handle, which
> > needs the ClientHeight.
> > And some window managers do not allow free resizing of windows, only in
> > non
> > 'ugly' steps.
> > And last but not least: Calculating the correct ClientHeight can depend
> > on a
> > lot of data, which a LCL interface may not have implemented yet for all
> > cases. The gtk and win32 interfaces are getting stable and complete, but
> >
> > we
> > already get three new interfaces: qt, wince and carbon.
> > Of course programmers don't want to wait years, until these interfaces
> > get the state of the gtk/win32 interfaces. Programmers want to use the
> > IDE and the LCL with their favorite interfaces, even if there are some
> > ugly todos.
>
> I see the following solution: try to implement IDE dialogs as good as
> possible for every interface.
> It is not wise to make IDE to look bad for all interfaces because
> interface Y has some problems. For example, even if only interface Z
> allow to make something better, do it only for interface Z (by using
> ifdefs or something else).
Yes. Instead of IFDEFs we should add an interface function to ask for the
capabilities of the current interface. This way the IFDEFs do not to be
checked every time an interface changed. I'm not sure, what capabilities are
needed. In case of MessageDlg it would be sufficient to know:
- if Canvas.TextExtent and GetPreferredSize of TWSButton works. Then the
calculated needed ClientWidth/Height is correct.
- if TForm ClientWidth/Height can be set freely (pixel exact)
Maybe something like this:
TWSWinControlCapability = (
icGetSize,
icGetPosition,
icGetClientSize,
icGetClientPosition,
icSetSize, // setting width,height pixel exact works always
icSetPosition, // setting let,top position pixel exact works always
icGetPreferredSize
);
TWSWinControl.HasCapability(const AWinControl: TWinConrol; Capability:
TWSWinControlCapability): boolean;
And a further global function for the canvas interface functions.
> Experiments are needed. I can take 2 IDE forms (simple-nonresizable and
> complex-resizable) and try to make them as good as possible. Then they
> will be tested on different interfaces and window managers to find any
> problems and try to fix them.
> I hope things are not so bad :)
How many window managers do you want to test? And how many option
combinations of those window managers?
> Compiler options is a good candidate for complex form. It need to be
> converted in lfm in any case.
> Any good candidate for simple dialog?
Compiler options is a good example for a resizeable window. It contains
edits and a memo.
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
