Panel design [was: Re: About the clock updates]

[Jasper Huijsmans]

Olivier Fourdan wrote:
[...]
> 
>>I think this is what gkrellm does as well. It will take a bit more 
>>memory, but it will be a lot more robust.
>>
>>This is quite interesting. GObject has some functions for making a 
>>'GBoxed' type. We could make a panel control a boxed type and add a copy 
>>function to the structure. Then if you choose a module in the dialog it 
>>is copied from the module module manger list. May not be worth the 
>>trouble though.
> 
> 
> I'm not thinking of coying objects, that's risky and would lead to nasty
> bugs IMHO.
> 
> I'm thinking of loading the module, and use the modules function "new"
> to create widgets on demand. No copy.
> 

In the boxed type system copy means create a new instance with the same 
properties. So it's the same, but on second thought I don't think it 
will be that useful.

The module list doesn't have to be a list of the actual widgets (my 
mistake I was thinking that), but they have to be loaded and unloaded 
once to retrieve their names. Names, id's and filenames are enough to 
identify a module for the purpose of the dialog.

One of the things the current system does quite nicely is it 'remembers' 
the settings for all modules in the dialog list. So if you edit an icon 
and change it to a trashcan, but then decide that you rather have the 
icon again, it still has retained its configuration. Not a big thing, 
but perhaps a nice to have.

> 
> 
>>Perhaps we could even make a new tab on the global config dialog for 
>>modules and let the user install or uninstall modules. Or just a button 
>>saying 'Update module list'. Well, I'm just brainstorming here.
> 
> 
> That would requires hooks in every modules, because what happen if a
> module is removed from the list while being present in the panel ?
> 
> Let's keep things simple, at first.
> 

Yeah, I get carried away sometimes ;-)

> 
>>Well the ref() part is there because I have to remove the widget from 
>>it's container every time the button position changes. The ref() is 
>>necessary to prevent it from being destroyed.
>>
> 
> 
> Removing a widget from its container destroy the widget ?
> 

Yes. If you create a widget it is in a 'floating' state with refcount 0. 
When adding it to a container the container takes a reference and the 
floating flag is removed. Removing the widget decreases the refcount, 
which is now 0 again and since it's not floating anymore it will be 
destroyed.

> 
>>There are probably more places in the code where I do this. Every time I 
>>unref a gtk widget (as oposed to a pixbuf, which may be unreffed) it has 
>>to be considered a bug!
>>
> 
> There are quite a few along the code...
> 

Bugs, bugs, bugs!

> 
>>As I said, you're help is very welcome. Ever since I made the big 
>>changes to have all panel components use the same interface I have a 
>>feeling that it's too complicated and there must be a way to simplify stuff.
>>
> 
> 
> Really glad you agree. I'm also really glad that, with xfce4, we start
> working as a team rather than we worked before (ie, one developper for
> one project).
> 

Yes that's really great. Much more a developer comunity. Nice warm, 
fuzzy feelings ;-)