I just wanted to put this idea out there, which I feel would bring significant pleasure to a lot of Lazarus users.

Would someone consider adding or working on support to theme the entire Lazarus IDE? I've found myself quite fond of darker themed IDE, such as VS code:

Darker themed IDE example
<https://msdnshared.blob.core.windows.net/media/2016/03/vsc1.jpg>

As it stand Lazarus has already the ability to change the color of the source code editor, and some support for changing the object inspector colors, and message window colors, but all three of these customization systems operate independently of each other. Also there are many other tool windows whose colors or styles cannot be customized, such as the components list in the object inspector, the project manager, and elsewhere.

An optimal solution would be to add a single IDE theme dialog allowing users controls the colors and default sizes of everything in the IDE. Items could be categorized in simple groups such as background color, text color/size, highlight color, border color/size, and so on. Color and size settings could be saved using a name, restored, and exported for others to use.

I can think of a few ways this could be implemented, mainly through offering a hook into the Graphics unit to redefine custom values for system colors, and a flag to denote values have been overridden.

If anyone has desire to communicate the pros/cons of this proposal (both of the concept and implementation) could you please it discuss here? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180309/94e6c45c/attachment.html>

 >theme the entire Lazarus IDE?

Big problem with scrollbars: Treeviews, Listboxes, Listviews, Synedits. I made big work to theme scrollbars in CudaText.

Oh, hell no!...

(sorry, but you asked)

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180309/717b6699/attachment.html>

Ralf, I believe your response was to to dark screenshot. I was hoping people would not consider one particular style and judge customization one that, but rather the idea of making customization of colors and size user accessible.

Regarding completeness of custom colors and themes, yes some items may not be easily themed, such as scrollbars. IMO though an attempt would not have to 100% complete at that start. That is, creating an simplified way to change some or most of the colors and size would be a good start. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180310/0f89569b/attachment.html>

Hi,
 
you can do it for Qt applications, just run Lazarus (or any Laz. project built as Qt) as:  
./lazarus -stylesheet mydarkstyle.qss
 
where mydarkstyle.qss must be valid Qt Style Sheet file, see: http://doc.qt.io/archives/qt-4.8/stylesheet.html#stylesheet  
V.

But again I've found scrollbars problematic since they look ugly when they're completely drawn by stylesheet :)

zeljko

zeljko wrote

But again I've found scrollbars problematic since they look ugly when they're completely drawn by stylesheet :)

I thinked about how to replace LCL scrollbas with ATScrollbar. Ie some LCL change which hooks SetScrollInfo too. Maybe it's possible to create ATScrollbars instead of OS bars and change them by SetScrollInfo. And change ClientRect of control.

On Saturday, March 10, 2018, Vojtěch Čihák via Lazarus <

built as Qt) as:

http://doc.qt.io/archives/qt-4.8/stylesheet.html#stylesheet

I think the issue with this is that some elements use pictures with fixed colors, and some elements do not honor style settings (like the TreeView in the component editor, which always has a white cell background).

A complete list would be helpful. Perhaps searching for instances where colors are set directly?

Cheers,
R0b0t1

significant pleasure to a lot of Lazarus users.

Would someone consider adding or working on support to theme the entire

Lazarus IDE? I've found myself quite fond of darker themed IDE, such as VS code:

... If anyone has desire to communicate the pros/cons of this proposal (both

of the concept and implementation) could you please it discuss here?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180310/5cef36c9/attachment.html>

+1

I can think of a few ways this could be implemented, mainly through offering a hook into the Graphics unit to redefine custom values for system colors, and a flag to denote values have been overridden.

What about the colors that have no counterpart in graphics?

Mattias

I like darker themes too - much easier on my eyes. Hence my eyes bleed [not really] when I look at Windows 10.

If somebody was to complete the LCL-fpGUI widgetset (so you can actually compile the IDE with LCL-fpGUI), then you could simply use the dark themes included with fpGUI and your solution is done. ;-) fpGUI applications can apply application specific themes and not depend on desktop environments. They can be switched at runtime too.

For examples of those dark fpGUI themes, see the Carbon or Plastic Dark themes shown here:

http://geldenhuys.co.uk/~graemeg/themes/start.html

I would imagine that the LCL-Qt interface could do the same, as that shouldn't depend on a desktop environment. Or does it?

Regards,
Graeme

Graeme, thanks for the feedback.

To everyone, I already have a plan for a basic theme system for all platforms which I'll be publishing as a design time package soon. It will work using text theme define files, and apply properties values to everything in the IDE using a pattern matching system with groups. It will search for published properties of all controls inside the IDE, changing them to the values specified in the define file. It will also provide a preview of changes to a select group of controls such that you can preview a theme by clicking on its name from a list of available themes.

The drawback to this approach is that some elements in certain toolkits aren't themeable using strictly property values. Scrollbars are one example already mentioned, but this problem also applies to some buttons, toolbars, page tabs, and I'm sure a few other things. But I think this will the best that can be hoped for given the current design of LCL controls.

I do have a plan to allow for theming of icons/glyphs inside the IDE, including the menu, tree view, and component icons. All revertible of course.

Finally, I believe the proper solution to a fully themeable IDE would be to use custom painted controls for the entirety of the IDE. It wouldn't really be that hard. I've coded my own tree view, list view, edits, buttons, menus and such from scratch on a few platforms. It would be more portable as well. It's just a bit tedious. If implemented it probably should use a more advanced graphics subsystem that does not mimic plain old GDI/TCanvas. I'll leave that someone else someday.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180312/9c19be53/attachment-0001.html>

Graeme, I looked at some on your fpGUI screenshots and some are quite nice.

What's the compatibility level of your controls with LCL controls code wise? Also, what graphics API are you using for different platforms? For example have you implemented a common advanced graphics API bridging Cairo on GTK, Direct2D on Windows, Quartz2D on OSX, and QPainter for KDE? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180312/4241a32f/attachment.html>

I don't think this is a good idea.

If you do this, then you're again offsetting a real solution by years by providing a half-baked solution that maybe satisfies an itch you have now, but fails to provide a long-term solution.

So if you do intend to make an effort (and I realize it is one), please do it on a lower level, namely the LCL. That can mean making fpGUI widgetset really usable for the IDE, or the customdrawn widgetset, or something else.

But at least then all applications can benefit from the effort.

There is nothing wrong with having vision and a long-term plan. But yes, it does take perseverance and resisting scratching an immediate itch.

Michael.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180313/72c5582d/attachment.html>

Sounds rather hackish to me :)

That would indeed be more aptly named :)

I believe this is the aim of fpGUI and the customdrawn widgetset. That is why I proposed extending them to the point of usability needed for the IDE.

Agreed.

My main concern is more "strategical":

Our time is limited (and by "our" I mean you too).

This "property pattern editor" - while it definitely has reasons for existing - will provide something halfway decent (because it can never do everything required for proper theming), and will most likely divert attention/time from the root problem...

But it is obviously a free world, I can only point out a concern I see...

Michael.

hehehe... And everything you mentioned there is already supported in fpGUI. fpGUI is a 100% custom drawn toolkit, with no 3rd party library dependencies. It includes a 100% Object Pascal based 2D rendering engine (called AggPas) which does anti-aliasing, and high quality sub-pixel rendering. fpGUI already supports theming - via code or external image resources.

The only part lacking from your wish list, is the LCL-fpGUI widgetset implementation. A lot is already working, but it still needs a bit more work to get the Lazarus IDE to compile with LCL-fpGUI.

Regards,
Graeme

Anthony Walter wrote

What's the compatibility level of your controls with LCL controls code wise?

fpGUI's controls can not be mixed with LCL controls. But the LCL-fpGUI implements a bridge between the two, making fpGUI controls behave like LCL developers are used to.

Also, what graphics API are you using for different platforms? For example have you implemented a common advanced graphics API bridging

Both. fpGUI v1.4.1 talks directly to the underlying OS platform's graphics API. That's Xlib for X11 based systems, GDI for Windows/WinCE etc. You as a developer don't need to worry about the differences, simply code using the TfpgCanvas class and the framework takes care of the rest. This also means fpGUI applications run pretty much everywhere without needing installations or megabytes of 3rd party libraries and DLL's (eg: Qt, GTK libraries are huge).

The "develop" branch of fpGUI does the same as before, but also has a new option... AggPas, which will become the default canvas and 2D rendering API. It is 100% platform independent, because it is 100% implemented in Object Pascal. And as I already mentioned in my other reply, it does anti-alias sub-pixel rendering as standard. It also has the ability to read TTF font files directly and thus incorporate high quality text rendering in the output too.

Regards,
Graeme

OI and other special IDE windows should indeed support theming. Now they have fixed colors.
However LCL itself already supports theming because it maps to native widgets. The native style + theme is used.
It means you should change a style for your entire desktop instead for Lazarus alone.

LCL has some complex components like TreeView which are custom drawn instead of native. Theming for them must be implemented using the theme services already included in LCL.
Adding an external theme support for LCL apps sounds like a very bad idea. It would combine the bad parts of a custom drawn and native widget libraries.
Mapping to native widgets is a clear design decision which has both pros and cons. Custom drawing everything is another design decision with its own pros and cons.

Or, maybe there is something about this issue I don't fully understand.

Juha

AlexeyT wrote

I made big work to theme scrollbars in CudaText.

TScrollBar is a native widget, isn't it? Why does it not follow the native theme?

Juha

It follows native theme of the widgetset, but not eg color setted up from lcl (well, Qt can handle that but not for mswindows and cocoa themes). I think that Alexey wants to customize scrollbars (eg with different color), but he cannot do so with lcl TScrollbar which is native widgetset control. Same as you cannot set TBitBtn.Color under win32 ws.

zeljko

Juha,

Thanks for the info about tree views. I had attempted to alter the theme on Linux with Qt4 widgetset and a stylesheet argument on the command line and I noticed the tree views were not taking on the styles I defined. I think they probably need to be adjusted to respect system colors at the minimum.

Regarding changing the OS theme to change the application theme, in some cases this is undesirable. For example some paint type programs, and even some code editors, use their own independent theme to subdue their interface <http://cache.getlazarus.org/images/photoshop.png> making the work more prominent. In these types of situations it's not reasonable to retheme the entire OS, rather just retheme an individual application. And of course in these situations an application theme is often a matter of personal taste, so the actual styling should be externalized. What we're left with is the logical solution, to support application level user defined theme information in external styling files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180314/48a720d6/attachment.html>

Ok, I understand.
I am not against such theming if somebody implements it.

Juha

Anthony Walter wrote

Regarding changing the OS theme to change the application theme, in some cases this is undesirable.

I've made that argument over 12 years ago to the Lazarus team, and every few years after that. They shot me down every time. Initially I wanted to use LCL and Lazarus IDE for enterprise based commercial software. All my clients wanted own styled applications - separate from the OS. LCL couldn't deliver [and for some more reasons] I had to leave LCL behind. I then implemented a whole new toolkit (and partly for fun and learning) to accomplish cross-platform development with FPC and that allows individual applications to be fully themeable.

I'm glad to hear that LCL finally has some sort of themeing interface, but based on these discussions, I guess it is not working 100% for all LCL based applications. At least the project is heading in the right direction.

Regards,
Graeme