GUIs - A Modest Proposal

[lkcl]

On Jun 14, 9:00 pm, Stephen Hansen <me+list/pyt... at ixokai.io> wrote:

> On 6/14/10 1:00 PM, lkcl wrote:
> >  what we typically recommend is that _even_ though you're going to run
> > the application "desktop" - as pure python - you still use JSONRPC [or
> > XmlHTTPRequest if JSONRPC is overkill].  so, _even_ though it's a
> > desktop application, you still run a local 127.0.0.1 web service (even
> > python -m SimpleCGIServer.py will do the job!)
>
> >  rick's article is highly illustrative on all these points:
> >    http://www.ibm.com/developerworks/web/library/wa-aj-pyjamas/
>
> Hmm. Depending on just how rich of a UI is possible, this is a slightly
> compelling idea.

 to be honest, if you don't put any effort in to use the appropriate
"lovely-prettiness" panels you can end up with something truly "90s-
esque".  but with a little effort you can do round-edged lovely colour
tabs:
   http://pyjs.org/examples/tabpanelwidget/output/Tabs.html

> Right now, I have to essentially maintain two separate
> code-bases: the desktop client and the web application.

 deep joy!

> In my scenario,
> both are actually lightweight (though not truly thin) clients to a
> master application server existing Elsewhere, that does the heavy
> lifting and manages all its users.
>
> Being able to take a code base and provide it to users as a
> traditional-seeming desktop application that works desktopy for them,
> with-- it sounds like-- two separate processes, one which is Python and
> is "serving" data, and more importantly accessing the MCP and getting
> instructions and doing its "lightweight" local lifting-- and another
> which is just a UI that communicates to that local server?

 basically, yes.  splitting things more along the traditional MVC
lines.  the M being the web server with JSONRPC to do traditional
Create-Update-Retrieve-Delete etc. and the VC bit being in pyjamas,
talking JSONRPC to the server *even* on the desktop version!

> Then one would run basically the same code on a server to allow remote
> access on some internet-accessible server, that sounds like what you're
> implying is possible?

 yes, even on the desktoppy version (because it's the same app)

> This time the server is still there, but the
> client UI is converted into pure JS and shipped to the persons machine.

 yup.

> That sounds too good to be true.

 yup, it does.  how can one person, a free software developer, have
come up with something like "The Holy Grail" of software development,
right?  when all the money in the world, from ibm, adobe, microsoft,
google, nokia and so on _hasn't_ managed it, in what... 20 years of
computer science, right?  i must be some sort of egomaniac, attention-
seeker, snake-oil-seller or just an outright liar, right?  those _are_
supposed to be rhetorical questions :)

> I sort of have to be reading too much
> into what you're saying.

 no, you got it.  does what it says on the tin.

 the "fly in the ointment" is that the success of pyjamas desktop is
critically dependent on its underlying DOM-bindings technology.
ironically, the non-free and proprietary dependence on MSHTML works
perfectly, whilst there are webkit developers *actively* destroying
the webkit-glib/gobject port, and the mozilla foundation developers
are trying desperately hard to break XPCOM (they've already side-lined
python-xpcom as "third party" now) because they're so "losing" so
badly to webkit that they are desperate to sacrifice everything to get
speed, speed, speed.

 l.