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. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev