First impression: libxfce4menu

[Brian J. Tarricone]

On Mon, 26 Mar 2007 08:48:42 +0200 Harold Aling wrote:

>Brian J. Tarricone wrote:
>
>> Odd that that's new - icon loading is done exactly the same way as it
>> was before, and, indeed, all icons are loaded using
>> gdk_pixbuf_new_from_file_at_size() using a global size, so I don't
>> see how this is possible.
>>   
>See http://sait.nl/menu2.png -> Screensavers icon (wasn't present in
>4.4 menu)

Good call, just noticed that menu icons are loaded differently from
application icons.  The app icons stupidly have a size hardcoded.  Can
you file a bug so I don't forget?

>>> - Icons are drawn after the text is drawn. This causes the text to
>>> shift x pixels to the right a fraction of a second later (probably
>>> more noticeable on slower pc's)
>>>     
>>
>> This is not new either.  Icons have been lazy-loaded for a long time
>> now (4.4.0 does this as well; I don't recall if any releases in the
>> 4.2 series do too). The original intent was to improve xfdesktop
>> startup time by reducing the time needed to generate the initial
>> menu.  If menu popup speed is an issue for you due to the
>> lazy-loading, I'd suggest not using SVG icons on older hardware.
>> They take orders of magnitude longer to load and render than PNGs
>> take. 
>I have a P4-3 GHz with 1,5 GB of RAM, which should be sufficient to 
>render SVG icons. If I notice the delay and the expanding on such a 
>machine, I'd reckon that it might be better to draw the menu with
>space already reserved for the icons. This will also prevent the
>overlapping of the menu as shown in http://sait.nl/menu.png ...

I'm not particularly worried about the delay - the icon drawing is
noticeable to me as well (on a slower G4 1GHz), but the delay is
minimal and perfectly tolerable to me.

The overlap is kinda lame, though; I hadn't thought of that.  File a
bug?

	-brian