[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons
Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons
Mon, 1 Nov 2004 02:41:38 +0100
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:
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
- a special folder should exist in ~/GNUstep/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.
- 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
Where have you picked this sentence ?
I'm beginning to get the feeling that you feel I am encroaching on
… 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
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
Well in the code below there is no support for nsmapping files
direclty inside theme packages but it is something which can be
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.
Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons, Quentin Mathé, 2004/10/30
Re: [RFC] [PATCH]: Icon themability patch for -GUI images/icons, Alexander Malmberg, 2004/10/31