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

[Jasper Huijsmans]

Hi Olivier,

Olivier Fourdan wrote:
> Jasper,
> 
> Regarding the size, it's the way it has to be, as we discussed on IRC.
> 
> If the clock is too big, either change the mode to digital and choose a
> smaller font or use the analog clock, or choose horiz. mode or remove
> the clock. That's it. This said, it's doesn't look that big to me
> anyway.
> 

Ok, agreed. Just thought I'd let you know in case you overlooked. It's 
still useable. It's just that it used to fit and now it doesn't, so it's 
a small regression, but that's alright in this stage of the development.

> As for the settigns, yes, I saw. Probably some side effects because I
> did not touch the save/load part at all.
> 

My guess is that the clock structure (not the widget) contains a value 
for the mode and that it isn't updated anymore. This should be an easy fix.

> Regarding this side effect, and also the double free bug (which appears
> to happen on any module, even if only one instance is displayed, so it's
> been there for a while) I'm not too happy with the current design. It's
> far too complicated and it showed yesterday that it's unmaintainable
> (neither Botsie, nor Xavier nor me could figure out what was done, how
> and why).
> 

I cannot agree more. It has evolved from a prototype I wrote from just a 
basic idea that it would be nice to have plugins. There has never been a 
  good audit of the design.

Keep in mind that I'm really learning all this stuff as I go along. Two 
years ago I didn't know anything about memory management in C. Now I can 
at least discuss it with you. Before I started xfce4 I didn't know 
anything about dynamically loading modules. Now I'm starting to 
understand things little by little.

It's been a great experience for me so far, but designing a software 
application is something totally new. I really appreciate any help you 
can give me on that.

> For me, the plugin part is a great idea, and you did a wonderfull work
> in writting this first, but we have to provide a rock solid base if we
> want to be able to build reliably uppon it (as I said, we are in the
> developpment process, we can break just everything that needs to be.
> Xine is a project that we should learn from, they are not affraid of
> breaking the API several times to improve things before the 1.0
> release).
> 

I have no problems at all with breaking API. The panel is small enough 
to not make this rather easy to do.

> So here is my proposal :
> 
> - Current design :
>   Load all modules from disk, all builtins modules, create widgets and
> all every time the user click on the control dialog.
> 
> - Proposed design :
>   Write a plugin manager that loads all modules once and only once at
> startup. If the dialog needs to change a module, it simply build a new
> instance of the module (using the "new" function) and unrefs the
> previous one.

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.

> No need to load all modules for nothing. The list of modules is given by
> the module manager that keeps a track of all existing loaded modules.
> Drawback: If the user install a new module, from a third party (!!) then
> it doesn't show in his control dialog until he quits/restarts the panel.
> That's however, very unlikely to happen. 1) there are no third party
> modules available yet and 2) even if that happens, I think the overhead
> of restarting the panel is nothing compared to headaches caused to
> developpers by the current design :)
> 

;-)

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.

> This doesn't necessarily mean a lot of woek. Most of the stuff are
> already written. It mainly requires a "reorganization" of the existing
> routines.
> 
> For sure, the controls_dialogs.c part will became a lot simpler. FYI,
> the bug comes from controls_dialogs.c
> 

Yes, I have to look into this more deeply. I changed it a bit this 
morning, but I don't think it will be solved.

> Also, I really don't understand why you need to ref() yourself the
> pc->base. It should not be required and if it is, it might be because
> there is problem with the design. 
> 

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.

However, the unreffing is a different story. When I started writing all 
this code I was under the impression that I had to unref it again before 
destruction. This is not the case I think. I just need to do a 
gtk_widget_destroy() if I want to get rid of it.

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!

> I really suspect that the numerous problems we have with the panel and
> its momory management come from the design.
> 
> Hope that helps, or at least I hope that makes sense. I' m willing to
> help on this if you wish.
> 

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.

Thanks,
	Jasper