New panel framework

[Jasper Huijsmans]

Erik Harrison schreef:
...
> 
> For those people who don't know where to look, perhaps you could
> provide download instructions? ;-)
> 

Hmm, maybe ;-)

svn co \
http://svn.foo-projects.org/svn/xfce/xfce4-panel/branches/experimental \
experimental

...
> 
> 
>>After that, please also have a look at the code and see if it makes
>>sense to you. For the plugin system read README.Plugins first.
> 
> 
> I'm no one to criticize C code, but it looks very pretty in there, and
> well laid out. Although I would hope that eventually Dbus could be
> used for IPC, there isn't anything that I could see that prevents that
> occuring.
> 

Yeah, the implementation can easily be changed. I'm not sure we need to 
change to DBus for this, but we certainly could.

> The plugin interface looks excellent. I gave it a relatively quick
> looksie, perhaps I should try porting or writing a plugin to see if it
> has any limitations.
> 

Yes, we should also discuss what kind of plugins should be included with 
the panel.

- program launcher
- window management: pager, tasklist, iconbox
- systray
- clock (maybe merge with date-time?)
- special action buttons: exit, settings, info, lock screen
- menu? <-- I'd like to have this as part of the panel, but in that case
   the menu code has to be moved to a library.

> I like that from the programmer's perspective there is not real
> difference in making an external or an internal panel item. I would
> however worry that if the examples ship as internal, then people will
> build internal plugins out of ignorance instead of necessity.
> 

Hmm, you have a point there. I'm not sure we should care too much, but 
maybe in README's/HowTo's/other docs we should encourage the use of 
external plugins.

>>
>>I'd like to know a few things:
>>
>>* Does it work?
> 
> 
> Yes. It crashed once on exit, out of the three or four times I shut it down.
> 

This is the biggest problem, since I don't yet really understand why it 
happens.

> 
>>* Does the dialog design and the available options look useful.
>>
> 
> 
> Mostly. I don't have that many monitors. ;-)

Hehe, that's for testing purposes. That part doesn't show up if you have 
only one monitor. So, at the moment I add every monitor four times ;-)

> 
> Perhaps we should be able to name panels when they are created? And
> then you right click on a panel, click configure, and the dialog comes
> up with that panel pre selected.
> 

The dialog does come up with the panel pre-selected that was last active 
(i.e. the one you right-clicked on). Not sure about the naming. GNOME 
does that, isn't it? I did think about adding a highlight to the 
selected panel.

> 
>>* Does the panel plugin system look like it will be able to support all
>>   current functionality?
> 
> 
> I don't know how well it maps to the current API, but it seems to
> support all of the functionalty that current plugins use.
> 

Which should be enough, I guess. I don't think porting will be too 
dificult. Most of the current plugin code could be reused. Biggest 
change will be the configuration, since it will have to use XfceRc, 
instead if xml.

> 
>>
>>I don't think it is time yet to start porting plugins, but it shouldn't
>>be very hard to do. Again, information about the plugin system is
>>available in README.Plugins.
>>
>>I know it sometimes crashes on exit. It probably has to do with
>>GtkSockets being destroyed while they are being removed from the panel.
>>Or something.
> 
> 
> That loop in clean up sets off alarms in my head for some reason. It
> seems like a dangerous to thing to do without locking the panel in
> some way, but I'm probably ignorant, stupid, or both.
> 

I'll check if I still can trigger the crash without it. I'm not sure 
exactly what gtk does when exiting the main loop.

> 
>>So, for anyone who has some time to waste and would like to help me
>>create a new panel for 4.4, here is your chance. Enjoy!
>>
> 
> 
> I wouldn't call it a waste 
> 

Thanks!