[Top][All Lists]

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

Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons

From: Quentin Mathé
Subject: Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons
Date: Mon, 1 Nov 2004 02:41:38 +0100

Hi Alex,

before my reply, I want to add I would appreciate that you take the time to have replies which respect basic formatting rules : spaces between the quoted text and your text… May be my mail made you upset, but not sure that's an acceptable reason :-)

Le 31 oct. 04, à 01:30, Alex Perez a écrit :

Quentin Mathé wrote:

Hi Alex,
it's nice to want to improve GNUstep theme support, but I must said I strongly disagree with your patch. - in my opinion, the themes support for icons or interface should not be supported at the GNUstep level but by a separate framework which can eventually be included in /gnustep/core and built when wanted. - trying to implement icons themes support without taking in account interface themes is a waste time because icons themes and interface themes have a lot in common, and they should be implemented with some coordination (although two frameworks can be used) - a correct icons themes support can be tricky to do especially if you consider the fallback issues or the file types relation (see the icons vs MIME discussion in the October 2004 FreeDesktop xdg list). - your patch reimplements something which already exists but in a way which is worst I think, because to create a theme now you need to write some code (I never saw a theme engine which involves such requirement) : nsmappings solution is way more easy (just a file to edit) and can eventually modified to support exactly what you doing in your code (with something like GSImagePatternName = "common_*" included at the beginning of the nsmapping file). Anyway I see with your solution that you want to allow with extra code what I would call a hack : the possibility to have theme icons anywhere on your computer, then why not install libraries in the same way… ;-) it is true that nsmapping doesn't permit that, but that doesn't mean that your solution is right…
- it gives no facility to support FreeDesktop icons themes.
Well, because you will probably ask what is my solution, here it is:
Icons themes implemented the right way should meet the following requirements : - a special folder should exist in ~/GNUstep/Library, /GNUstep/System/Library, /GNUstep/Local/Library, GNUstep/Network/Library where you can install themes in the same way you add fonts or whatever resources.

What do you propose to call the folder?

I have proposed "Themes" in my mail… What you do you think ?

- a theme should be loaded only for to the user who chooses to use it

The same is true with icon loading with my patch.

well ok.

- the icons themes and interface themes should use the same packaging
They are just bundles.....with Resources folders....

Here is the main problem I explained in my previous mail, it's not something acceptable to have themes which are bundles (in the case bundles are loadable pieces of code with some extra resources). Themes should just be folders (eventually opaque in the Workspace) which contains resources but no code.

- the icons themes and interface themes should have the possibility to override specifics application

yes this is always necessary with apps like Gorm.


An interface theme will be a collection of images used to draw the widgets (a pixmap theme if you want) and eventually icons, an icon theme would be an interface theme which contains just icons.

Our patches address similar but different things.

No, or I should say yes but in a way which is absolutely not friendly, not flexible, and very limited. What you mean by "different things" ? I would say your patch handles less things not differents things.

Everything you've written so far sounds logical, except for the "you never want to icon theme without an interface theme" which is an absolutely absurd statement, which both you and rIO made.

I never said that "I never want an icon theme without an interface theme", because you are right it is absurd. And I don't think rIO made such statement.
Where have you picked this sentence ?

I'm beginning to get the feeling that you feel I am encroaching on your turf.

… You are somewhat paranoiac. I will be very happy that you finish to code NSToolbar, fix NSTableView, work on the IconKit or whatever :-), but like any open source developers which implements a thing on his spare time, if somebody contributes to "my" code, I would like he does the thing correctly. Precisely I would enjoy if he does the thing better than what I would have coded myself ;-). Well moreover in this case, it is not my turf because I'm not working on themes support, and similarly I'm not a -gui maintainers then it is not me who will take the decision to apply your patch or not… But what I dislike in your way to act is that Nicolas has been working hard on Camaelon which is a theme engine, which means that icon themes support are related to it, and you… you are just creating a quick patch on your side without any discussions with Nicolas (I can be wrong here…), you submit it, then you are upset about me because I said what I'm thinking about it as you request… By such acting, I would understand that Nicolas could be somewhat upset. I see two options which are right here in my opinion : you collaborate with Nicolas on Camaelon for GNUstep themes support or you develop your Themes framework (eventually merged into -gui if the maintainers want it) if you think you can produce something which is better than Camaelon.

Now here is a basic implementation of it with a modified NSImage class in a way to make -imageNamed: more modular and easy to override, and a category to NSImage which would be included in the theme engine (like Camaelon or whatever).

Per an IRC-discussion with Alexander Malmberg, I did express some concern about overriding the entire imageNamed class, because the performance hit of making it search through numerous other folders may or may not be negligible.

I haven't said my code is bullet proof, some caching is probably needed or may be we can have more efficient code by implementing it a bit differently.

Well in the code below there is no support for nsmapping files direclty inside theme packages but it is something which can be added.

It would at least be a decent reason to keep NSMapping around, because it's used for more or less nothing as it stands right now.

May be. As you said NSMapping can be useful with themes package and may be in the future with some other uses too… I think we should keep it, it's not a big complexity layer.


Quentin Mathé

reply via email to

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