About the clock updates

[Olivier Fourdan]

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.

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

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).

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).

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.
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 :)

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

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. 

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.

Cheers,
Olivier.


On Thu, 2002-09-26 at 08:15, Jasper Huijsmans wrote:
> I have found two (small) issues with the new clock code:
> - The clock doesn't remember its settings anymore.
> - The clock is a bit big in vertical mode, small size (see
>   attached screenshot). It's not much, but it does stretch the panel a
>   bit.
> 
> 	Jasper
> 
> 
> -- 
> IRC channel: #xfce on irc.openprojects.net
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at moongroup.com
> http://moongroup.com/mailman/listinfo/xfce4-dev
-- 
Olivier               <fourdan at xfce.org>            http://www.xfce.org
-----------------------------------------------------------------------
XFce is a lightweight  desktop  environment  for  various *NIX systems.
Designed for productivity,  it loads  and  executes  applications fast,
while conserving  system resources. XFce is all free software, released
under GNU General Public License.    Available from http://www.xfce.org