Re: question about panel info in status report

[Jason Gilbert <jason scott net>]

George wrote:
> 
> well teh code hasn't yet been done ... the reasoning for separate
> processes is this: it makes it simpler and more consistent .... I'll
> probably have some "applets" which are in the panel code itself (launcher,
> menu,logout) ... there set can be separate processes .... it's not much
> of an overhead and makes creating applets simpler ... you don't need to
> subclass or anything, you call a function, get maybe an event_box and
> do your stuff on there .... basically no redundant code in applets ...
> plus it makes it easy for applications to have an applet that is up only
> as long as the app is ... say you run an app, it registeres it's applet
> and then when it quits the applet goes out ... and it's very simple ...

If you're already going to include some "applets" anyway, why not just
make it possible to add simple applets.  You could still have an applet
that swallows or contains a separate process.  That way all applets
would be treated the same.

> it also makes applets easier to write (you don't have to worry about one
> code being used by two applets, and it makes the whole thing just a lot
> nicer, look at email notification applet, only one can be on screen) ...

You wouldn't necessarily only have one email applet.  What if you have
multiple accounts that you want to monitor separately?

> the config of the applet can just be a "static" and this will reduce code
> needed to produce a well behaved applet ...

You could also have all the basics for the applet included in a base
applet class that is subclassed.  Then you would automatically have a
"well behaved applet".
You could also include standard menus items in the base applet class and
then subclasses could add additional menu items if they wanted.
 
> plus how many applets would you have to have running before it became a
> problem  (given most of the ones on someone's screen will be launcher's
> and menus and I plan to build those in) 

My point remains, if you're going to build in someone.  Why not make it
a standardized API people could use.

> another advantage to these things is that if an applet segfaults it
> doesn't bring down the whole panel ... and that's become something
> bad .... the panel itself (well the odler version) rarely segfaulted by
> itself it was the applets that took care of that job ...

Hmmm, I would imagine you would still have to watch out for external
apps croaking??

> also anotehr thing ... if an applet segfaults and you exec the panel
> in your .xinitrc .... your X dies ... I don't think tehpanel proccess
> should do ANYTHING else then what it needs to do .. since it needs to
> be rock solid ...

Actually, people should start gsm in their .xinitrc.

Basically, it sounds like there will be built in applets anyway, might
as well be able to extend that way.  To me, it seems that the panel
should just be a container that sits on the desktop and can be hidden. 
It also has a container that holds the application menu, applets, etc. 
It seems like all the applet containment code should be separate from
the actual panel code.  This doesn't appear to be the case now. just my
$0.02 worth.

BTW, what's a drawer.  I'm assuming it's a menu that slides out (like
the application menu).  If that's the case, why is it different from an
applet?
wouldn't it be just a particular kind of applet.  There appears to be
separate code to handle them.

jason

-- 
Jason Gilbert | http://www.scott.net/~jason/ | http://www.mantissa.com/

"The total job will be in the software, and we'll be able to write big
fat programs. We can let them run somewhat inefficiently because there
will be so much horsepower that just sits there. The real focus won't
be who can cram it down in, or who can do it in machine language. It
will be on who can define the right user interface and properly
integrate the main packages." -- Bill Gates, PC Magazine 1982