[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: idea : faster pixmap loading for opMenu
From:       David Faure <faure () alpha ! tat ! physik ! uni-tuebingen ! de>
Date:       1999-04-29 18:28:07
[Download RAW message or body]

On Thu, Apr 29, 1999 at 07:48:31PM +0200, Simon Hausmann wrote:

> > But I agree that we'll have problems if we pass only the filename if the
> > icon is in the client application's own directory (share/apps/..../),
> > because then the host can't find it.
> > Two solutions : pass a fullname, or keep the current methods.
> 
> I still vote for additional methods: Being source compatible by keeping
> the old pixmap transfer stuff and providing new methods for faster pixmap
> loading.

> Well, on the one hand this bloats up the whole interface (and the IDL
> generated code) a lot, but on the other hand keeping source compatibility
> is a thing I started to like, especially after my OpenParts-Unicode
> conversion, which involved hundres of changes all over Konqy/KOffice ;-)
I see your point... but I would have voluntereed, for that one ! :)

I'm for keeping existing methods only if we actually need them.
Not for source compatibility. koffice is not released yet, it's still time
to get things right.

> And beside this: Switching to the new methods breaks pseudo-compatibility
> to the qt/kdeui classes, and I think keeping this compatibility is
> important keep the whole usage of PartsUI easier.
Not really. It's a matter of definition. In qt/kdeui, a QPixmap is passed.
In a partsui, we can choose between passing an encoded IDL "Pixmap" class 
or a pixmap name. It's still "I'm building a menuitem with that pixmap".

> btw: I agree that using a lot of pixmaps in menus is slow using the
> current UIUtils conversion stuff, but otoh: This conversion is only
> done when (re-)activating the MainView part (in case of Konqy) , and I'm
> not sure whether this will be done so often? (currently it is done only
> once on startup) 
Wrong - it is done on each main view creation (i.e. main window creation).
Every time you open a new konqy window, even in the same process, this happens.
And startup time is very slow because of this too (ok, I really have a lot
of bookmarks !)

> And I think most of the time when using Konqueror only part child switches
> occur (which do not involve massive changes in Konqy's GUI ) .
yes, but new windows are created VERY often.

> But I know, my argument is not very strong since Part
> activation/deactivation is done pretty often in KOffice, and when
> switching between huge GUIs like the ones from KPresenter and KWord I can
> understand you :-)
:)

-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]