Re: Stock icons
Mike Morrison wrote: > There is a bug open for this. I posted a comment on it a while back > . > > https://bugs.maemo.org/show_bug.cgi?id=223#c11 > > On Mon, Sep 8, 2008 at 10:22 AM, Jeffrey Barish > <[EMAIL PROTECTED]>wrote: > >> I don't understand where stock icons come from on Hildon. I looked >> in /usr/share/icons and /usr/share/themes, but I am finding mostly pngs >> with names that start with qgn which do not seem to be icons. For >> example, >> I am using the "redo" stock image. Where is Hildon getting it from? >> -- >> Jeffrey Barish I would like to see the bug that you cited fixed, but I was interested only in knowing where maemo gets the icon for redo. I did a find from / for anything with redo in it and come up with one icon (/usr/share/icons/hicolor/26x26/hildon/qgn_toolb_sketch_redo.png), but that's not the icon that appears in my program. I have browsed the obvious folders but did not see the icon that appears in my program. -- Jeffrey Barish ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stock icons
There is a bug open for this. I posted a comment on it a while back . https://bugs.maemo.org/show_bug.cgi?id=223#c11 On Mon, Sep 8, 2008 at 10:22 AM, Jeffrey Barish <[EMAIL PROTECTED]>wrote: > I don't understand where stock icons come from on Hildon. I looked > in /usr/share/icons and /usr/share/themes, but I am finding mostly pngs > with names that start with qgn which do not seem to be icons. For example, > I am using the "redo" stock image. Where is Hildon getting it from? > -- > Jeffrey Barish > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Stock icons
I don't understand where stock icons come from on Hildon. I looked in /usr/share/icons and /usr/share/themes, but I am finding mostly pngs with names that start with qgn which do not seem to be icons. For example, I am using the "redo" stock image. Where is Hildon getting it from? -- Jeffrey Barish ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
On Thu, 2005-10-27 at 20:34 +0200, ext Frantisek Dufka wrote: > > There should be other reason for using glibc, like that it is better and > not slower or not substantialy bigger or something like this :-) Or > maybe you cannot compile Opera of Flash player with it. GTK and xfree > seems to work at least on i386 I'm sure there are, I just can't comment on the exact details as I wasn't evaluating libc. My guess would be maturity, wider developer base and better localisation support. But maybe we can get someone with the details offer a few words? -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
On Thu, 2005-10-27 at 11:31 +0300, ext Eero Tamminen wrote: > Hi, > > >> My suggestion: Forget about this as long as you don't offer a similar > >> feature to replace the builtin stock icons. > > My guess would be that Tommi has some long term plan to fix this > properly when there's time. :-) The longer term plan, or at least an idea, is to fix this correctly by replacing the builtin stock icons with our own as the gtk+ icons don't match the overall look anyway and are of different size etc. Unfortunately our infinite number of mon^Wartists can't produce quality graphics in such a short notice (one of the things we should've planned better, but mistakes happen.) The memory problem exists and can be fixed now. With little more effort it can be fixed even without the side effects everyone is worried about. The quick fix exists now, it was never intended to be the final version. It just takes longer to come up with the "right" fix, with your help it'll happen faster. -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
On Thu, 2005-10-27 at 13:49 +0200, ext Florian Boor wrote: > Tommi Komulainen wrote: > > There's probably a more simple solution to make stock icons work well; > > just add "gtk-bold.png" and similarly named files in the hicolor icon > > theme and things should just work. However the current solution works > > that's a good idea... expecially because you can ship properly looking icons, > but you can't do this by installing a package which makes this good solution > pretty useless :-( Umm.. installing icons under /var/lib/install... is supposed to be working. It may be that XDG_DATA_DIRS has wrong value in the release that was included in the developer devices, but in later releases '/var/lib/install/share:/var/lib/install/usr/share' is appended so icons should work. (User-installed themes should also work, though I'm not sure the personalization applet can handle them.) -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
Gustavo Sverzut Barbieri wrote: Could you do some tests if basic maemo platform compiles with uclib and how much space it saves? Both static (file size) and dynamic (apps running). Maybe, but not in very near future. I still haven't got the device and when I get it I will try something easier first or something more interesting or practical. I was mainly interested if someone else was already thinking about this or not. If it proves valuable nokia people may consider. I don't think so. It is probably too late for such change. Once you see shipping maemo binaries from 3rd parties based on glibc it is not very practical to change such core part of system. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
On 10/27/05, Frantisek Dufka <[EMAIL PROTECTED]> wrote: > Eero Tamminen napsal(a): > >>I know this is pretty bold comment from me but if you think 30KB is > >>enough to break compatibility, why not to use uClibc instead of glibc or > >>ipkg packaging system from Familiar instead of full dpkg and .deb? > > > > > > Package database and tools don't consume RAM. > > > Well they take flash space and RAM only when executed. Bigger binary and > database may also flush file cache that could make the device feel > slower after installing something. sure > > uClibc is not binary compatible to Debian. Glibc and the Maemo Gtk > > are both. You can for example take Debian ARM strace binary directly > > from debian repo and copy it to the device and it works... > > Yes, but is such binary compatibily useful? Do you actually repackage > anything direcly from debian without any changes? Is recompiling too > much work? Will the target audience for N770 actually try to install any > debian package for ARM (like strace or something gtk based) when there > is even no terminal in production version? +1 > There should be other reason for using glibc, like that it is better and > not slower or not substantialy bigger or something like this :-) Or > maybe you cannot compile Opera of Flash player with it. GTK and xfree > seems to work at least on i386 > > http://www.emdebian.org/links.html - Erik Andersen's uclibc version of > Debian > http://people.debian.org/~andersee/uwoody/main/binary-i386/ > > I know everybody went with glibc (Sharp on Zaurus, Familiar for iPAQs) > but if performance is priority and everything for the platform has to be > recompiled anyway, uClibc based system may save more than 30KB of RAM > per proccess. Or maybe not or there are other problems. I don't know the > answer, that's why I asked. Could you do some tests if basic maemo platform compiles with uclib and how much space it saves? Both static (file size) and dynamic (apps running). If it proves valuable, nokia people may consider. -- Gustavo Sverzut Barbieri --- Computer Engineer 2001 - UNICAMP GPSL - Grupo Pro Software Livre Cell..: +55 (19) 9165 8010 Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] Skype: gsbarbieri GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
Eero Tamminen napsal(a): I know this is pretty bold comment from me but if you think 30KB is enough to break compatibility, why not to use uClibc instead of glibc or ipkg packaging system from Familiar instead of full dpkg and .deb? Package database and tools don't consume RAM. Well they take flash space and RAM only when executed. Bigger binary and database may also flush file cache that could make the device feel slower after installing something. uClibc is not binary compatible to Debian. Glibc and the Maemo Gtk are both. You can for example take Debian ARM strace binary directly from debian repo and copy it to the device and it works... Yes, but is such binary compatibily useful? Do you actually repackage anything direcly from debian without any changes? Is recompiling too much work? Will the target audience for N770 actually try to install any debian package for ARM (like strace or something gtk based) when there is even no terminal in production version? There should be other reason for using glibc, like that it is better and not slower or not substantialy bigger or something like this :-) Or maybe you cannot compile Opera of Flash player with it. GTK and xfree seems to work at least on i386 http://www.emdebian.org/links.html - Erik Andersen's uclibc version of Debian http://people.debian.org/~andersee/uwoody/main/binary-i386/ I know everybody went with glibc (Sharp on Zaurus, Familiar for iPAQs) but if performance is priority and everything for the platform has to be recompiled anyway, uClibc based system may save more than 30KB of RAM per proccess. Or maybe not or there are other problems. I don't know the answer, that's why I asked. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Fixing the stock icons issue
Hi, To get back to the problem.. The problem is that whether you use the builtin icons or not, the instant you load the first icon you get the 30k penalty per process. This shouldn't be necessary and the gtk+ team has said they'd be willing to consider a patch that changes the lookup priority so that builtin icons are loaded only as last resort, when absolutely needed. The comment in gtk/gtkicontheme.c(theme_lookup_icon) is misleading, there's no need to search builtin icons first. Should be relatively straightforward thing to fix for someone with interest and time in their hands. -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
Hi, > I know this is pretty bold comment from me but if you think 30KB is > enough to break compatibility, why not to use uClibc instead of glibc or > ipkg packaging system from Familiar instead of full dpkg and .deb? Package database and tools don't consume RAM. > I know Familiar distribution used ipkg because full dpkg was overkill > and used glibc mainly for better compatibility with other arm/debian > based devices but if Maemo is different anyway and don't care about > compatibility why not to try uclibc? uClibc is not binary compatible to Debian. Glibc and the Maemo Gtk are both. You can for example take Debian ARM strace binary directly from debian repo and copy it to the device and it works... Maemo is only visually "incompatible" to Gtk. :-) (different themes, theme-engine, and now also icons) - Eero Ps. If you look closely at the product file system, you'll notice that the product uses both glibc and uclibc (not at the same time though :)). ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
Tommi Komulainen wrote: This message was brought to you by the performance police. The builtin stock icons compiled in the gtk+ library are causing extra >30k dynamic memory consumption regardless of whether they're ever used. In 770 all icons are coming from the icon theme anyway, so this is a cheap and simple optimization to do. And everyone loves to have better performance, right? :) I know this is pretty bold comment from me but if you think 30KB is enough to break compatibility, why not to use uClibc instead of glibc or ipkg packaging system from Familiar instead of full dpkg and .deb? I admit I still don't have the device so I'm watching all this from a distance but I am curious why you went for full glibc and dpkg. Did you evaluate uclibc and ipkg at Nokia and found it is not good enough? Or is glibc and dpkg not considered bloated in embedded devices anymore? I know Familiar distribution used ipkg because full dpkg was overkill and used glibc mainly for better compatibility with other arm/debian based devices but if Maemo is different anyway and don't care about compatibility why not to try uclibc? I also admit I now lived in PalmOS world for few years so my knowledge about recent changes in linux on ARM is a bit outdated and I actually never tried uclibc on ARM, only i386. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
2005/10/27, Tommi Komulainen <[EMAIL PROTECTED]>: > The only places where things might get broken is when the builtin stock > icon is the only piece of information provided to the user such as in > the toolbar in an appview - gtk+ toolbars should always have icon+text > information provided as per HIG and a11y guidelines. Icons should be > used only in addition to other forms of providing information, relying > on icons only (in gtk+) is questionable already. Yeah, but makes sense in a space-constrained environment, specially if you can use the same icons that everybody else uses so users are familiar with their meaning. > So only a very small part of applications should be impacted. Disagree. Stock icons have more uses than just as a part of a stock item. But if you assert that icons are not important, I guess it doesn't matter... > And in case there are any misconceptions about priorities, product comes > first, Hildonized apps second, running unmodified gtk+ apps is plus. Unfortunately that means that those without a graphics department at their disposal or graphical skills are left without icons (or worse, have to make bad icons themselves). > Removing stock icons has only positive impact on the product and only a > minor negative impact on a subset of other apps. It's positive only because the product uses it's own icons and will have negative impact on the open source software created for it. But I guess that is fair enough to be in the bottom of the priority list :( > And the effort spent was around half an hour to implement. From where I'm > sitting that's quite cost-efficient. It is cost-efficient *because* you are sitting where you are sitting. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Hi, Tommi Komulainen wrote: > There's probably a more simple solution to make stock icons work well; > just add "gtk-bold.png" and similarly named files in the hicolor icon > theme and things should just work. However the current solution works that's a good idea... expecially because you can ship properly looking icons, but you can't do this by installing a package which makes this good solution pretty useless :-( > In our UI guidelines menu items or buttons don't have icons so this is a > moot point. Yes, the implementation could be better, but the end result Right - but the most important widget makes use of them: The toolbars and that's exactly the place where stock icons should be used to ensure a consistant and themable look and feel. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Hi, > i don't think 30k is worth making it a major pain maintaining applications > which > support both plain GTK and Hildon UI. But that's my personal opinion. > In addition to this you loose a pile of convenient functions to deal with the > stock icons. UI guidelines (e.g. the Gnome HIG) suggest to use a set of well > known symbols for common operations which is a really good idea if you want > users to feel familiar with their applications - another important feature you > will loose with this. I do agree with this. > Additionally it might be a good idea to replace the builtin icons with maemo > style icons... currently some of them look pretty good (like the arrows, > useful > to replace the broken GtkArrows in the default theme), but some look very different. Replacing the icons with the maemo ones makes more sense. It will make it easier to port applications. For example programs that use the stock gtk icons wont need to replace them to make them more consistent with the maemo/hildon look. Saving the effort of a lot of ifdefs if the program is intended to be running on other systems too, if the porter is even willing to do so... Performance wise it might improve application performance for maemo apps as they will not have to load the icons from flash, instead they will be directly available. On top of that programming is a bit easier too and there is no risk of letting out icons by accident (however I have to admit with a standard icon set that chances are pretty slim) Anyway I believe removing the stock gtk icons will also decrease the interest of developers wanting to port their applications. For a performance improvement that is probabely negligable. (GPE just copes fine with those stock icons in) There might be better things to go after, unfortunately my gtk knowlegde is not that good... (yet) Regards, Philippe | Philippe De Swert | | GPE developer: http://gpe.handhelds.org | Emdebian developer: http://www.emdebian.org | | Please do not send me documents in a closed | format.(*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | http://www.gnu.org/philosophy/no-word-attachments.html --- A free anti-spam and anti-virus filter on all Scarlet mailboxes More info on http://www.scarlet.be/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Let me reiterate the consequences of removing the builtin stock icons (not items, icons): it has no ill effect on stock menu items or stock buttons (the icon has always been considered optional, see gtk-button-images and gtk-menu-images GtkSettings.) The only places where things might get broken is when the builtin stock icon is the only piece of information provided to the user such as in the toolbar in an appview - gtk+ toolbars should always have icon+text information provided as per HIG and a11y guidelines. Icons should be used only in addition to other forms of providing information, relying on icons only (in gtk+) is questionable already. So only a very small part of applications should be impacted. Yes it is a bit more work to really integrate with the maemo platform, but much less than porting to HildonApp. And in case there are any misconceptions about priorities, product comes first, Hildonized apps second, running unmodified gtk+ apps is plus. Removing stock icons has only positive impact on the product and only a minor negative impact on a subset of other apps. And the effort spent was around half an hour to implement. From where I'm sitting that's quite cost-efficient. For the most parts our priorities are well aligned with those of other developers and we try to keep it that way. When some of our decisions doesn't align perfectly with the outside it usually just means that we don't have the resources to do things perfectly so we choose to do something that works for us. If it doesn't work for you we need you to fill in the gap. (In fact I have a patch waiting in my inbox, thanks Skyhusker, but I haven't had the time to look at it closely yet.) There's probably a more simple solution to make stock icons work well; just add "gtk-bold.png" and similarly named files in the hicolor icon theme and things should just work. However the current solution works for us, so it is not high in our priority list to do this work. (In the longer term we should have correct size images to replace the stock icons as the stock sizes don't quite match ours.. but again, it would take more time.) On Wed, 2005-10-26 at 19:32 +0200, ext Florian Boor wrote: > UI guidelines (e.g. the Gnome HIG) suggest to use a set of well > known symbols for common operations which is a really good idea if you want > users to feel familiar with their applications - another important feature you > will loose with this. In our UI guidelines menu items or buttons don't have icons so this is a moot point. Yes, the implementation could be better, but the end result would still be the same for most parts. > Additionally it might be a good idea to replace the builtin icons with maemo > style icons... currently some of them look pretty good (like the arrows, > useful > to replace the broken GtkArrows in the default theme), but some look very > different. This is a good idea, and we should've done that long time ago. But we didn't and there's only so much we can do in the short term now. -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Hi, >> My suggestion: Forget about this as long as you don't offer a similar >> feature to replace the builtin stock icons. My guess would be that Tommi has some long term plan to fix this properly when there's time. :-) >> It might be a good idea to >> modify GTK in a way that only the the stock icons used by an application >> are kept in memory instead of compiling them into the library. The builtin stock icon pixel data isn't paged into memory from the library code unless application uses that. AFAIK that 40KB memory (including the allocation overhead, not just sum of allocations) is used for strdup()ing the icon names, creating objects that are not used etc, not for pixel data. > What are 30kb when you look at GTK2 ;-) One step in making it smaller. The memory usage can be lowered only by fixing all these little details, not by some magic incantation... I'm pretty sure Gtk developers would have noticed if there's some unnecessary 1/2MB allocation hiding in an obscure corner of the code. :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Hello, I also think this is not a good idea, either be compatible with desktop linux (and pay the price to slow and huge) or not and have the advantage of having a really fast and slim platform - but in my eyes any step between is not really worth the trouble. What are 30kb when you look at GTK2 ;-) lg Clemens ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] gtk+ builtin stock icons removed
Is it possible to have these extra icons and stuff application installable package ??? Br, Devesh > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of ext > Florian Boor > Sent: 26 October, 2005 20:32 > To: Komulainen Tommi (Nokia-M/Helsinki) > Cc: maemo-developers@maemo.org > Subject: Re: [maemo-developers] gtk+ builtin stock icons removed > > > Hello, > > Tommi Komulainen wrote: > > This message was brought to you by the performance police. > The builtin > > stock icons compiled in the gtk+ library are causing extra > >30k dynamic > > memory consumption regardless of whether they're ever used. > In 770 all > > icons are coming from the icon theme anyway, so this is a cheap and > > simple optimization to do. And everyone loves to have better > > performance, right? :) > > i don't think 30k is worth making it a major pain maintaining > applications which > support both plain GTK and Hildon UI. But that's my personal opinion. > In addition to this you loose a pile of convenient functions > to deal with the > stock icons. UI guidelines (e.g. the Gnome HIG) suggest to > use a set of well > known symbols for common operations which is a really good > idea if you want > users to feel familiar with their applications - another > important feature you > will loose with this. > > My suggestion: Forget about this as long as you don't offer a > similar feature to > replace the builtin stock icons. It might be a good idea to > modify GTK in a way > that only the the stock icons used by an application are kept > in memory instead > of compiling them into the library. > Additionally it might be a good idea to replace the builtin > icons with maemo > style icons... currently some of them look pretty good (like > the arrows, useful > to replace the broken GtkArrows in the default theme), but > some look very different. > > Greetings > > Florian > > -- > The dream of yesterday Florian Boor > is the hope of todayTel: 0271-771091-14 > and the reality of tomorrow.Fax: 0271-771091-19 > [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] > > 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Hello, Tommi Komulainen wrote: > This message was brought to you by the performance police. The builtin > stock icons compiled in the gtk+ library are causing extra >30k dynamic > memory consumption regardless of whether they're ever used. In 770 all > icons are coming from the icon theme anyway, so this is a cheap and > simple optimization to do. And everyone loves to have better > performance, right? :) i don't think 30k is worth making it a major pain maintaining applications which support both plain GTK and Hildon UI. But that's my personal opinion. In addition to this you loose a pile of convenient functions to deal with the stock icons. UI guidelines (e.g. the Gnome HIG) suggest to use a set of well known symbols for common operations which is a really good idea if you want users to feel familiar with their applications - another important feature you will loose with this. My suggestion: Forget about this as long as you don't offer a similar feature to replace the builtin stock icons. It might be a good idea to modify GTK in a way that only the the stock icons used by an application are kept in memory instead of compiling them into the library. Additionally it might be a good idea to replace the builtin icons with maemo style icons... currently some of them look pretty good (like the arrows, useful to replace the broken GtkArrows in the default theme), but some look very different. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] gtk+ builtin stock icons removed
FYI, Starting from gtk+2.0 2.6.4-1.osso75 the builtin GTK_STOCK_* default icons will be removed in order to save precious memory. It should have little impact on applications, stock menu items and buttons will simply not display the icon which is supposed to be optional anyway. However if your application is relying on having a stock icon visible (such as in the toolbar) those instances need to be updated. There are plenty of funnily named icons in the platform for you to use, and in the worst case you can always package your own icons. Sorry for the inconvenience. This message was brought to you by the performance police. The builtin stock icons compiled in the gtk+ library are causing extra >30k dynamic memory consumption regardless of whether they're ever used. In 770 all icons are coming from the icon theme anyway, so this is a cheap and simple optimization to do. And everyone loves to have better performance, right? :) -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
