Hi,
Quentin Mathé wrote:
The main motivation behind the change was to make easier to port existing
themes. For porting a pixmap theme, I think Thematic is not the right choice.
The porting should be simple as possible: put the images in some directories
inside a theme bundle and just edit some plist files for the name mapping. The
approach we implemented with Eric supports this, and bring the following
benefits:
I disagree here. I think we shouldn't complicate GNUstep to follow
different theming styles. Our Theme stuff, even if incomplete, is
already quite a maze. I think Thematic should be central part of a
pixmap theme design or, in case, conversion.
Thus a "port" of an existing theme should be done from Thematic. If
there are certain styles or standard to adapt, it should have an
"import" feature, but "saving" should generate a standard-style gnustep
theme.
This doesn't mean GS's theming mechanism shouldn't be improved. I try to
create 3 themes since years and struggle quite a bit and currently I
gave up on one of them, because of the difficulty of setting the colors
as I want.
- the image are looked up through a mapping so the image file name doesn't
matter (you can keep the original theme image name for the image file, it's a
very important point to make easy to port and track changes in ported themes)
But this implies clearly another level of mapping which we currently can
avoid: just drop the images in the ThemeImages directory and they work.
This is useful also because Thematic doesn't support al controls and
most of the theming is currently done by replacing directly the images
in its images inspector.
- color customization (would be nice to support a single human-readable plist
which can contain eithe RGB or Web color instead of multiple binary plists)
Agreed that it is difficult. I don't care about how the colors are
written. THe problem is currently knowing which colours to modify and
what they effect, this is absolutely not easy. Again I think thematic is
the solution for setting them, I'm not interested in the manual
intervention in a theme bundle.
I think we have essentially "too few colors", thus I cannot selectively
change some colors without affecting others.
- turn the GNUstep default theme into a real bundle (the theming code and the
image lookup is more complex than it ought to be because the default theme
isn't a real theme bundle)
That's a problem even Windows has. The advantage is that it always
works, but the disadvantage is of course "lack of consistency", thus I
essentially agree.
1. it must be backward compatible and continue to use the old image names where
themes still use them
2. it must be OSX compatible ... not introducing new incompatible naming for
any of the standard OSX images
3. existing GNUstep software must be updated in sync with it (ie existing
themes and Thematic.app must be updated to support new changes)
The change was intented to comply with 1) and 2), and not require 3). I'll fix
the bugs in the current code and ensure it works correctly with various
existing themes and Thematic without requiring any changes.
Ok, let's see, I'll test it with my themes. I had Sleek quite close
finally to a first decent release, so this was kind of a set-back.
We might discuss colouring in a separate thread. Right now I just put
the development of the "dark" ThinkDark theme on hold.
Riccardo
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev