Re: proposal: talking to the app manager

On Sun, May 04, 2003 at 04:28:56PM -0300, Lalo Martins wrote:
> As part of the path to better app managers, I'd like to propose
> an API for apps to talk to app managers (for example, to make a
> window-list applet possible).  There are two ways to do that:
> 
> 1. assign a widget handle to the app manager and allow it to
> receive APPMSG.  A new server resource would hold the handle of
> the app manager.  This is not bad, but feels a tad kludish to me.

I really don't like that :)
The app manager isn't an app, nor is it a widget. It owns widgets, but
that's all implementation-dependent.

> 
> 2. create a new request to send stuff to the app manager.

This is probably best. It would be nice to have a generic way to call a
method on an object, but that's pg2 territory.

Also, unless there's a good reason to lump all appmgr requests into one,
I'd go for making each of these functions separate pgserver requests.

> 
> AFAICS, this API needs to have these "functions":
> 
> - register(handle):
>   the widget at 'handle' will be notified when a new app is
>   registered and when a running app is closed.  When this is
>   called, a notification is sent back for all apps that are
>   already running.  'Toolbar' apps don't cause a notification.
> 
>   Notifications can be sent via APPMSG or WE_DATA - which is better?

How about dropping the handle, and having it send non-widget events to
the client that called it? An event with PG_EVENTCODING_DATA is
definitely better than an APPMSG, and it would be best to define a new
type of event rather than using WE_DATA. (WE_DATA is just for events
that pgserver doesn't really know the format of. That's not the case
here)

It's also worth looking at the regowner and unregowner requests. The
comments say they're for registering exclusive access to a resource.
This isn't exclusive access, but perhaps they can be generalized?

> 
> - unregister(handle):
>   for symmetry, but perhaps it is not needed (a widget is
>   'unregistered' when it is deleted).
> 
> - switch(handle):
>   'handle' should be an app.  The app manager does whatever is
>   necessary to ensure it is displayed: uniconifies, moves to top
>   of stack, (in case of the panel appmgr) resize to nonzero, etc.
> 
> - cycle():
>   display the "next" app.  The meaning of "next" is up to the
>   app manager.  This could be used for example by an input
>   filter that traps alt-tab.
> 
> Is this sufficient?  Does anyone have a requirement that this
> doesn't meet?

Besides the close() that you mentioned in the other email, I can't think
of any off the top of my head. I am concerned about security though-
IMHO not just any app should be allowed to call close().

Of course, that's a whole can of worms that pg1 doesn't even touch. If
you want to do something nasty, you can tell the server to allocate a
huge bitmap, or create a popup covering the whole screen with no way to
close it. I should probably just put aside any hope of security against
these types of DOS attacks until pg2 :)

--Micah

-- 
Only you can prevent creeping featurism!


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf