gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep don't load images of current theme.


From: Quentin Mathé
Subject: Re: GNUstep don't load images of current theme.
Date: Mon, 22 Jul 2013 17:58:38 +0200

Hi,

Le 20 juil. 2013 à 16:26, Riccardo Mottola a écrit :

> 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.

Thematic is just a thin layer above GSTheme and the theme bundle format is easy 
to edit directly (color lists put aside), so I don't see why Thematic should be 
used all the time. 

A theme editor would be a nice application. However we have limited manpower, 
as a result I'm personally more interested in improving the theming support 
accross AppKit classes rather than improving Thematic.

>> - 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.

Color customization needs some serious improvements, I agree.

>> - 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.

ok

>>> 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.

I just fixed the missing theme image bug you reported with r36916. I also did 
some extensive testing using Thematic, Gorm and the following themes from GAP: 
Neos, Sleek and ThinkDark. If you observe any other bugs, let me know about 
them.

Cheers,
Quentin.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]