Fantastic information, and all good news.  Sheesh, this is like tag-team red-carpet treatment in here!  Am I detecting a certain, shall we say, *eagerness* for us to start doing some cool Protein stuff? :-)

I think you may be right about there being some confusion out there about what "multi-tasking" means in Cobalt.  That's pretty understandable, but I wonder if there's a way to help people "catch the vision" a little more clearly *before* they start digging in to Protein too much.  Surely you guys (that's a gender neutral term where I'm from) have thought of some interesting things that you think 3rd party developers might do with Cobalt that they haven't been able to do with Garnet related to this area of multi-tasking. How about an article that's a collection of "Cobalt dreams" from different PalmSource engineers that describe stuff they wish somebody would try?  

In any case, thanks a lot, all... now go home.  It's the weekend!

David
---
David Beers
Pikesoft Mobile Computing
www.pikesoft.com
719-963-2319
Skype ID: pikesoft


On Fri, 3 Jun 2005 18:42:36 -0700, Dianne Hackborn wrote:
> Hi David!
>
>> OK. Now what's actually happening here?  Say I launch my
>> stock-ticker and then open my web browser and navigate to a
>> page.  The stock-ticker is written so that its thread stays
>> alive even after getting an appStopEvent and the browser gets
>> a normal launch in an application process.  But say I've got
>> something more than just a ticker going on in that window
>> attached to the background process: maybe a field and a
>> button to submit a new stock to track.  From what I
>> understand, both apps (or threads rather) receive their own
>> events so they can each have their own event loops, right?
>> The browser can continue to fetch and render a page while I
>> tell the ticker to fetch new stock data.  I can tap one part
>> of the screen and interact with the browser, another and
>> interact with the ticker.  For all intents and purposes this
>> would be running two apps simultaneously... but I didn't
>> think we were quite doing that with Cobalt... so I'm a little
>> confused.  The scenario I'm describing seems to make
>> background and application processes almost indistinguishable
>> in terms of what can happen within them.  Is that really the case?
>
> I wrote an article with a sample application implementing a background
> magnifier that might help make this more concrete:
>
> http://www.palmsource.com/developers/newsletter/20050104.html
>
> This program keeps a thread running in the background process, which
> does UI and other things.  When it is launched as the main application,
> it finds that running background thread and communicates with it.
>
> So basically, everything you describe is correct.  One possibly
> important correction is that your main stock ticker thread wouldn't stay
> around after receiving an appStopEvent -- instead, when the user runs
> it, it would launch -another- thread in the background process that is
> the thing staying around.  When the user switches to another
> application, your "main" stock ticker thread exits (and the process
> hosting it is destroyed), but the background thread can remain alive as
> long as you want.  You are free to split work (UI and otherwise) between
> these two threads as you want, with only a few limitations described
> below.
>
> I guess we need to be more clear in what "application" means when saying
> we don't support multiple applications running at the same time.
> Basically this means that there can only be one application at a time
> that gets the full complete set of services a Protein application
> expects.  The services we are interested in here include:
>
> * Its own dedicated process.
> * System-supplied mechanisms for the user to manage the application.
> * The ability to receive and invoke sublaunches in the traditional way.
> * The ability to use back-buffered windows (both transitional and legacy
> styles).
>
> An application running in the background does not get access to the
> above features from its background thread, but can do pretty much
> anything else it wants there.  Of course all current Palm OS
> applications are dependent on those features, so there is no way to take
> two existing random applications and have them run together at the same
> time.
>
> For new Protein applications you write, however, any thread (in any
> process) can call the WinStartThreadUI() API, at which point it has a
> complete UI context associated with it, from which it can do nearly all
> the UI stuff you normally expect (with the restriction that it must use
> update-based windows).  The UI architecture works pretty much like you
> would expect from a full traditional OS, where the OS takes care of
> dispatching events to the correct window and managing all interactions
> between them so that they don't know about each other.  Similarly, there
> is a new background notification mechanism that allows you to receive
> notifications without temporarily becoming the "main application" in
> order to process the sublaunch.
>
> I think the big thing we are missing for real multiple-application
> support is the very high-level application model: what it means to have
> multiple applications running at the same time, how the user experiences
> that, and facilities to manage and manipulate them through the UI.
> Right now, when you want to start doing this stuff, you are pretty much
> on your own as far making it happen and how that gets presented to the
> user.
>
> On the plus side, however, I think we have most of the tools available
> for enterprising third party developers to address these shortcomings.
> In particular, there is an API allowing you to iterate through all of
> the running background threads, through which you can retrieve their
> event queues to communicate with them -- for example to get an icon and
> name for the thread, ask it to exit, etc.  If a developer wants to come
> up with some standard messages for doing this kind of interaction with
> background threads, we would be very open to adopting them for the
> platform.
>
> ----
> Dianne Hackborn
> Manager, Application Frameworks, PalmSource
> dianne.hackborn@palm...
>
>
> ---To unsubscribe send an email to leave-protein-forum@news...




---To unsubscribe send an email to leave-protein-forum@news...
--
For information on using the P