Re: question about panel info in status report

[George <jirka 5z com>]

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

why make it so complicated to add applets .... the applets that are going
to be "part" of the panel code are those which are actually just the basic
panel functionality ... anything else has nothing to do with the panel ...

> > 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?

my point exactly .... but it's much much easier to do that as two separate
processes (given that one applet can't look into more mailboxes)

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

the problem is the otehr code ... but this is beside the point ... most
of the funtionality doesn't have anything to do with the actual
functionality of the applet .... all teh applet writer has to do is to
call a function that will return a widget, then build his applet on
top of that ... very simple ... and no special applet stuff ... it's
almost like writing a simple gtk app ...

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

why .. tehre are going to be applets that are basically the panel
functionality in some way ... and they use some of the internal panel
functionality .. and the panel migth use some of theirs .... but for
an applet such as the cd player or the clock ... the panel will not use
that and their codebase can be completely separate ...

it will be much simpler for the applet writer if it's separate processes
...

> > 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??

why ....??? if something dies, it dies .. doesn't affect the panel ....
if a dynamically loaded applet dies .. the panel dies ...

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

the "applets" that are going to be built in, will NOT be applets ... they
will be internal panel functionality ...

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

a drawer is say a button which has a panel of it's own into which you will
put applets .... as such it there are many things that differentiate it
from an applet

George

-- 
------------------------------------------------------------------------------
George Lebl <jirka@5z.com> http://www.5z.com/jirka/
------------------------------------------------------------------------------
While some may have the year 2000  | $ emacs
problem, my 64-bit alpha's got the | bash: emacs: command not found
year 292471208677 problem          | YES!!