Leo looks ugly and inconsistent with a dark Qt theme

[zpcspm]

First, I will provide a bit of context.

I'm currently experimenting with creating an eye-candy dark-themed
desktop. I'm using Linux, but I'm not using GNOME or KDE.

Currently, my setup consists of:

- a dark fluxbox theme (fluxbox is my window manager of choice)
- a dark gtk2+ theme
- a dark gkrellm theme (gkrellm is a system monitor)

These play well together and look good.

The missing piece of the puzzle are qt GUI apps.
It is possible to make them use the gtk theme with gtk-qt-engine.

Here is how a qt app (qbittorrent) is looking with it:

http://i.imgur.com/7pPcM.png

Now here is leo:

http://i.imgur.com/63mfJ.png

I see many problems here:

- there are a lot of places where the gray color looks unreadable due
to a hardcoded (probably that qt CSS template from leo settings) light
background: the button labels, the tree headlines, the minibuffer, the
status line
- there's some void white background behind the multitabbed log panel
- the splitter color is not consistent with the dark theme, I would
expect it to be dark as well
- the dark theme interferes with the hardcoded color values used by
the colorizer, see those hardly readable "python" and "main()" in the
body panel

For comparison, see how gvim is looking:

http://i.imgur.com/Oaezf.png

gvim is a gtk app, so this last screnshot illustrates two points:

- the look of qt and gtk apps stays consistent (this is good)
- the look of gvim and especially the code in gvim is much more eye-
candy than in leo. Normally, I wish that leo could look like gvim by
default

Ideally, there will be some feedback on this rant of mine here and
probably a wishlist bug will be filled at launchpad then.

[Edward K. Ream]

On Fri, Nov 12, 2010 at 4:43 PM, zpcspm <zpc...@gmail.com> wrote:

> The missing piece of the puzzle are qt GUI apps.
> It is possible to make them use the gtk theme with gtk-qt-engine.

I don't know. However, I would consider the present situation to be
"buggy" only if certain colors could not be changed with user
settings. There may be one or two areas of Leo's screen where this is
true. For example, bug 323967: leo overrides minibuffer background
color.

Edward

[zpcspm]

I might try to play a bit with colors in qt-gui-plugin-style-sheet
setting in the near future to see if there is some potential for
improvements there in the context of my scenario.

Is it possible to reload the modified content of myLeoSettings and
have leo automatically apply the updated stylesheet to its GUI without
explicitly restarting it?

[zpcspm]

I did some tweaking to the qt CSS, here is my current progress:

http://i.imgur.com/9RBGO.png

Besides the mentioned problem with the minibuffer background, there
are some more.

I couldn't find anything related to the script buttons in the style
sheet. If by any chance mod_scripting initializes them using hardcoded
values for colors and fonts, it will be good to have these settings in
the style sheet too. Even if mod_scripting is a plugin, it is a very
important one and it is enabled by default.

Some parts of the colorized body text are not visible as well, looks
like a clash between my custom black background and the color used for
certain patterns by leo.

Text selection in body is decent: http://i.imgur.com/wgeCj.png

[zpcspm]

On Nov 13, 9:51 pm, zpcspm <zpc...@gmail.com> wrote:
> Some parts of the colorized body text are not visible as well, looks
> like a clash between my custom black background and the color used for
> certain patterns by leo.

A partial workaround is to use @nocolor in node bodies. Thus my dark-
themed leo becomes suitable for taking notes but not fully suitable
for coding yet. This makes me wonder if it is possible to tell leo
"use @nocolor for the whole current outline" without having explicit
@nocolor directives in node bodies.

[Edward K. Ream]

On Sun, Nov 14, 2010 at 8:45 AM, zpcspm <zpc...@gmail.com> wrote:
> On Nov 13, 9:51 pm, zpcspm <zpc...@gmail.com> wrote:
>> Some parts of the colorized body text are not visible as well, looks
>> like a clash between my custom black background and the color used for
>> certain patterns by leo.

I'm convinced that this is a more serious bug, having several parts:

1. Many log messages use "red" or "blue" colors, and that's just wrong
on a dark background.

The solution will likely be to use g.note, g.error, g.warning and
maybe one or two others, then allow the font colors to be chosen "en
masse". That is, we want to eliminate all hard-coded colors in Leo.

2. It is difficult or impossible to set colors for certain ui objects
at present. Everything must be settable.

I have just upgraded the status of the following bug:
https://bugs.launchpad.net/leo-editor/+bug/323967
Leo overrides minibuffer background color

This bug will be where the theme-related issues get addressed.

Edward