Michael,

I agree with you somewhat that my proposal isn't a total solution, but
perhaps there is another point of view to consider that has been
overlooked.

And that is this:

There ought to be a way to edit component properties sweepingly either in
an application or in the IDE.

I say this because I have often edited the Lazarus source to make remove
toolbar button captions, change edge borders, fix the position of edit
boxes, increase the height of a panel, turn on tool tips. or remove an
unneeded panel. All for the effort of adjusting layouts to make the IDE
space more efficient, fix what I see as a design problem, or create a
layout better suited to a personal taste.

Allowing anyone to easily make sweeping changes like these to the IDE, and
making those changes easily shareable and modifiable without the need to
search for the correct lfm, or pas file to edit and recompile the IDE would
be a good thing. That is, imagine being able to group alter properties of
controls/components within the IDE (or any application written with
fpc/laszarus), and see those changes instantly, and easily reverted,
without the need to search for files and rebuild.

As such I think that there is merit to such a tool. It might not need to be
branded as a "themer" or "skinner". Perhaps as a "property pattern editor"
or something thereof.

Regarding a long term solution, I agree that would be best. What I would
see as the optimal way to handle this would be to use entirely owner drawn
controls based which depend on external resource files, to determine styles
such as color, sizes, padding, font, alignment, glyphs, and visibility
among a few potential possibilities. Actual control drawing would be
handled through an abstraction layer to a platforms best possible graphics
API to efficiently handle antialiasing, smoothing, subpixel, and hdpi
rendering in a manner that makes it complete transparent to controls. This
would allow one code base for all controls for all platforms, solving not
only layout problems among different widget sets, but also behavioral
problems that creep into usage due to difference or restrictions of the
underlying native widgets.

Of course, such a design should be completely optional to allow people to
continue using native controls whenever they want, but if they're
interested in a totally themeable and consistent usage applications across
all platforms, then using this alternate widget set would be a pleasant
second option.
-- 
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Reply via email to