xfce design and impl. ideas

[Jasper Huijsmans]

On Mon, 27 Oct 2003 03:22:57 -0800 (PST)
Sridhar R <sridharinfinity at yahoo.com> wrote:

> hi,
> 
> Increase in features will decrease the speed.  This is
> wrong and one should code apps in a way that makes
> such statements false!
> 
> I propose some techniques mostly on xfce4-panel.
> 
> 1. First xfce4-panel should be memory efficient 
>    in its algorithms and semantics so that loading
>    of many more plugins won't consume much memory.
> 
> 2. Just consider the notes plugin.  It is not often
>    needed.  So it can be stored in disk.  When it is
>    needed it can be loaded (dlopen()?).
> 
> 3. But not the others, like clock plugin.
> 

Plugins are already dlopened shared libs. Unloading unused plugins is
planned, but not trivial.

> 4. Don't store configuration data-structures in 
>    memory.  For example, in notes plugin text may
>    not be stored in memory (except in gtkentry)
>    Store/read from disk.
> 

Configuration that is used is in memory, configuration that is not, is
not ...

> 5. xfrun4 need not be a seperate executable.  Pressing
>    Alt+F2 to load xfrun4 takes some time, since
>    it has to read the code from disk and load it
>    into memory.  Instead if it is built in into one
>    of the xfce components code, it will open faster.
>    

Yeah, let's put all components in one executable ... oh, wait ... the
entire concept of xfce4 is build on separate executables for separate
tasks!

That said, xfrun is not intended to be used all the time, so a small
startup delay is not much of a problem. Use minicmd otherwise.

> 6. In general, there should be a architecture, that
>    supports caching up executables on disk!
>    xfcache4??
>    

Yeah, right. Let us know if you have written one.

	Jasper