Zitat von Giuliano Colla <[EMAIL PROTECTED]>:
>[...] Michael Van Canneyt ha scritto:
> >
> > On Mon, 21 Jan 2008, Giuliano Colla wrote:
> >
> >> Florian Klaempfl ha scritto:
> >>> Lord Satan schrieb:
> >> [...]
> >>>> That's correct. And if they had used OpenGL for it, it would be
> >>>> hardware accelerated, cross plattform and good looking, too. And we
> >>>> would need no stupid Aero or Compiz or other composition managers.
> >>>> And we could do things other widgetsets could only dream of. And
> >>>> porting to OpenES would be easy, too. Stupid Lazarus developers.
> >>> That's simply not the aim of the lazarus developers. They are interested
> >>> in native gui support and high vcl compatibility, no more, no less.
> >> That's the real catch. They're not stupid, but they're faced with an
> >> impossible task: to implement conflicting specs.
> >>
> >> vcl implies a number of precise, consistent specs, which dictate component
> >> behavior. They're the real value of Delphi.
> >>
> >> Native widgetsets implies a number of specs (often vague and loosely
> defined)
> >> which are different from vcl, and don't map into them.
> >
> > The VCL doesn't dictate anything, it's a wrapper around Win32 native
> > controls, so at least that widgetset should "work".
> >
>
> It provides properties and methods which are in most cases
> self-explanatory. The Color Property of a Form or of a Button dictates
> its color. Well, try just to set this property to clRed, or clButtonFace
> with different widgesets, and compare the behavior.
This is a question of priority.
Some widgetset developers and some lazarus developers think that changing the
'color' is seldom a good solution and so they don't invest time on this. So it
is up to those who think, that this property is useful to implement and
maintain it. If the implementation breaks other features then the developers
have to decide what is more important.
> > I doubt Borland went as far as to specify a set of consistent specs.
> > At least I never saw them. And the behaviour changed (subtly) over the
> > versions of Delphi/Windows as well.
> >
> > You can discuss forever about this. The only thing that the Lazarus people
> > can try to do is make the widgetset behave as consistent as possible over
> > all widgetsets, without sacrificing the native look they get by using
> native
> > widgets.
> >
>
> Or they could achieve native look just by using a Bitmap, and consistent
> behavior with code in LCL, with less duplicated work, less bugs, and
> better results.
>
> > Instead of putting a lot of time in such mostly useless debates (its not
> > the first, and probably not the last) it would have been better to report
> > possible bugs or - better yet - provide patches to improve the behaviour.
> >
>
> When you're told that the feature can't be implemented because the
> widgetset doesn't support it, you stop reporting.
>
> When you see that the development line is to move the implementation
> from LCL to widgetset, instead of the opposite, (and breaking what was
> already working in the process), you stop providing patches, and start
> whining. :-(
Breaking is bad, but sometimes inevitable.
For example Drag and Drop was improved in the LCL/gtk, but without a proper
threshold, so treeviews become unusable on some machines. I will not complain,
because the general direction is right and if no one fixes it I will fix it
myself. Even though I already fixed it in the past.
About: move from LCL to widgetset
That was the goal of lazarus from the beginning.
If you want a visual component library with a minimal backend, then use fpGUI or
msegui.
Keep in mind that using the native widgets has several advantages:
- native look. Even when user switches theme or OS.
- widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input
method, assistive technology, hardware acceleration, network support (X
client/server modell).
So basically every drawing should be avoided in the LCL or at least use only
high level drawing functions.
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
