Panel design [was: Re: About the clock updates]
jasper at moongroup.com
Thu Sep 26 11:01:54 CEST 2002
Olivier Fourdan wrote:
> 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
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
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
> 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
> 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.
More information about the Xfce4-dev