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 wor
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. :-)
T
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 soluti
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 easie
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 .d
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
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
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 c
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
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 shi
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) sugges
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 i
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 sto
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 ;
a-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
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,
16 matches
Mail list logo
