I've been away from trunk for a few weeks due to problems. I notice that the old "LCL Widget Type" on the Compiler Options -> Paths page has been replaced by a build mode entry which sets a macro, but the dropdown for this doesn't have a "default" entry to match the current IDE.

Has "default" been totally lost, and does this have any implications for the .lpi which I think used to have this as an option?

I also note that the GTK entry is no longer marked deprecated, despite no longer being actively supported.

Mark Morgan Lloyd hat am 18. April 2012 um
11:38 geschrieben:

I've been away from trunk for a few weeks due to problems. I notice that the old "LCL Widget Type" on the Compiler Options -> Paths page has been replaced by a build mode entry which sets a macro, but the dropdown for this doesn't have a "default" entry to match the current IDE.

The default is chosen, when you set nothing, i.e. delete the LCLWidgetType macro from the list.

Has "default" been totally lost, and does this have any implications for the .lpi which I think used to have this as an option?

The "default" was only shown in the IDE. Internally it was always the empty string. But an empty string was confusing in the comboxbox, so a "default" was shown instead.

I also note that the GTK entry is no longer marked deprecated, despite no longer being actively supported.

Yes.

The LCLWidgetType is now a normal package macro and you can provide a list of values for such macros, but you can not add comments to values.

AFAIK the old notes (alpha, beta, deprecated) did not help much. To choose a widgetset a developer need a list like
http://wiki.lazarus.freepascal.org/Roadmap.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120418/dfd20abd/attachment.html>

Just my 2 c:

I feel it was a really great idea to allow for multiple "build mode variables". fpGUI makes good use of that by allowing for defining the backend behind the fpGUI layer. (Hopefully CustomDrawn once will do the same.)

Moreover I can think of a lot more advantageous uses of additional future "build mode variables" for allowing to customize any packages.

-Michael

Although I think having a "build it like it looks in the current IDE" setting is useful, and having an indication that some targets are obsolete or immature is essential.

Just my tuppence-worth.