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

[Quentin Mathé]

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.

ok

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

--
Quentin Mathé
address@hidden