Re: Portability between PicoGUI1 and 2

On Wed, Apr 16, 2003 at 04:21:09PM +0200, Roland Seuhs wrote:
> Am Mittwoch, 16. April 2003 13:17 schrieb Micah Dowty:
> > On Wed, Apr 16, 2003 at 11:58:54AM +0200, Roland Seuhs wrote:
> > > Hi,
> > >
> > > Before everybody gets coding for PG2 and PG1 becomes unsupported:
> > >
> > > How portable will PicoGUI apps be across platforms? Will you be able to
> > > recompile a PicoGUI1 program on PG2? Is a recompile even necessary? (That
> > > would be perfect of course ;-)
> >
> > The current plan is for there to be a compatibility layer in the form of
> > a cli_c and cli_python ported to pg2. This will mean you can run pg1
> > apps on pg2 with no recompilation, but that currently server-side
> > components like drivers and widgets will need porting.
> 
> But this means that you would have to rewrite a PG1 program (from scratch ?) to the PG2 architecture if you want to have a "real" PG2 program or want some new features, is that correct?
> 

Yes.

There are parts of the API that will for sure change. The new object
model will make way for a lot of cleanups and neat features.

Forexample, when you set the text of a label widget, it doesn't have to
be a string- just an object that implements the methods required by the
label widget. Whenever the string changes, the label will observe that
hange and update itself. This means you could write a clock, for
example, by making a string-compatible object that represents the
current time, and pointing the label at that.

By using observers and a more MVC-like programming model, a lot of
problems in the current design can be solved. Currently if you want a
very large scrolling document, you'd have to send the entire thing to
pgserver. In the pg2 architecture, you could specify a data source
object implemented in the client, and it would only be accessed as it's
needed.

There will probably also be a different layout engine. The divtree
served pg1 well, but pg2 will probably have something higher level. I'd
like to see applications specify the relationship between widgets
abstractly. A text editor could specify that this textbox widget is the
most important item in the application, then it could categorically list
actions you can perform on that textbox. The theme could be involved in
deciding how to represent that. Maybe it generates a menubar, maybe a
floating palette, maybe a configurable toolbar. The application would of
course have to give hints, but I'd like to see even more of the
application's layout moved. This is an important part of PicoGUI's goal
of running the same apps in diverse environments.

--Micah

-- 
"For every problem, there is a solution that is simple, elegant, and wrong."
           -- H.L. Mencken


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