[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: Nicolas Roard
Subject: Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons
Date: Sun, 31 Oct 2004 23:11:12 +0000

Le 1 nov. 04, à 01:41, Quentin Mathé a écrit :

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

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

more exactly, we can have two kind of "themes", as I see it. First, there is the "gui bundles" loaded via GSAppKitUserBundles default; thoses can contains code, and in fact can be anything, not just theme. That's how WildMenus or Camaelon works. The second possibility is to have "pixmaps" themes : just a bunch of pixmaps in a bundle, loaded by some kind of theme engine. That's my
goal for the next release of Camaelon.
"Code" themes are possibly faster than "pixmaps" themes. On the other hand, creating a "pixmap" theme is much easier for a non-programmer,
and can also feature more "rich" displays.
Theses definitions in mind, effectively, "pixmaps" themes shouldn't need any code at all.

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

yes this is always necessary with apps like Gorm.


hm, why would it be necessary for Gorm ? To the contrary, I think it's quite useful to have Gorm using the current theme :-)

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 guess it's probably my fault yesterday when we discussed on the irc channel, I was perhaps not clear enough in my explanations. What I said is that for me, an icon theme will be exploitable directly by Camaelon (for Camaelon, it will just be a normal pixmap theme, which only happend to contains icons). As anyway for an user you want to have some kind of methods for managing simply your themes, and as I really don't think having such theme management thing have its place in -gui, I was just saying that if an user want to use themes, he'll use Camaelon or something similar. There's no need in my opinion to add some half-done theme icons support in -gui while we have gui bundles for doing that.

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.

Well, I'm not "upset" -- I honnestly have others preoccupations in my life than being upset by a patch, and I'm not even a gnustep maintener -- I just find this patch non-optimal and providing little interest. I'm perhaps wrong but for the moment I'm frankly not convainced... give me convaincing arguments, that's all I ask !

Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
 -Arthur C. Clarke

reply via email to

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