gui platform

[quick]

I'm curious as to whether XULrunner was considered as a GUI basis for
Hotwire instead of GTK. I'm only lightly familiar with both, but my
impression of the former is that it uses Cocoa on the Mac and
therefore doesn't need the non-native X-server implementation that GTK
would require. This would seem to solve some of the MacOS discussion
issues on the hotwire wiki.

I also noticed that the code is divided into hotwire/ and hotwire_ui/,
but there seems to be lots of gtk stuff sprinkled in the core
elements: any comments on how hard it would be to do something like
support multiple base GUI's (e.g. have a GTK version and a XULrunner
version)?

[Colin Walters]

On Mar 26, 2:48 pm, quick <qu...@sparq.org> wrote:
> I'm curious as to whether XULrunner was considered as a GUI basis for
> Hotwire instead of GTK.  I'm only lightly familiar with both, but my
> impression of the former is that it uses Cocoa on the Mac and
> therefore doesn't need the non-native X-server implementation that GTK
> would require.  This would seem to solve some of the MacOS discussion
> issues on the hotwire wiki.

There was an earlier discussion about this; see:
http://groups.google.com/group/hotwire-shell/browse_thread/thread/e63c009e37e8d3aa?hl=en

But I have been thinking a lot about the long-term direction for the
project platform recently though; some of this is reflected in my
recent blog entries.

One thing that occurs to me is that Hotwire is not a very traditional
GUI app in many ways, and so we don't really need the full power of a
toolkit like GTK+. The latest UI was somewhat unnatural to code in GTK
+.

In that thread I did mention I liked Mozilla/XulRunner myself too, but
the problem with that is that Mozilla has pretty weak operating-system
level interaction bindings. Their "subprocess" equivalent
(NSCreateProcess or something) is not great, and we would need custom
bindings to open pesudoterminals, etc.

Also, let's be honest. JavaScript sucks =) The prototype class
model...ugh. ES4 is fixing a lot of this stuff, but that's Firefox 4/
Mozilla 2 timeframe.

I guess PyXPCOM is an option, but I don't have any experience with
that.

> I also noticed that the code is divided into hotwire/ and hotwire_ui/,
> but there seems to be lots of gtk stuff sprinkled in the core
> elements:

Yeah, the problem is that sysdep/ is both GUI deps and non-GUI deps.
I guess the right thing is hotwire/sysdep and hotwire_ui/sysdep.

> any comments on how hard it would be to do something like
> support multiple base GUI's (e.g. have a GTK version and a XULrunner
> version)?

It would be interesting to try something similar in XULrunner, even if
it only shared some of the code or was a fork. The powerful HTML/DOM
interaction could make something like the overview a lot cooler,
potentially.

But what I find myself running up against more now is limitations in
CPython, such as the single-threaded nature and the inability to
cancel threads, and the fact that Hotwire can't run anything except
Python.

[Hamish]

Just a quick thought that if hotwire becomes successful there will be
a split between the core code and GUI code (so that the core can run
on a remote server that may not have any gui code).

In which case, it will be possible to write other front ends - qtwire,
xulwire, maybe even a plain text version (to run on the server over
ssh when the local machine does not have hotwire installed. For
parallels you could look at xterm, gnome-terminal, konsole, cygwin ...
which all provide ways of using terminals inside a gui window.

But this is all somewhat distant in the future, if at all ....

[Colin Walters]

On Apr 5, 11:44 am, Hamish <dmi...@gmail.com> wrote:
> Just a quick thought that if hotwire becomes successful there will be
> a split between the core code and GUI code (so that the core can run
> on a remote server that may not have any gui code).

I tried to make that split originally; the hotwire/ directory was for
code that didn't "import gtk", and hotwire_ui/ for the rest. But the
sysdep/ directory messed things up. It probably wouldn't be a lot of
work to untangle though.

> In which case, it will be possible to write other front ends - qtwire,
> xulwire, maybe even a plain text version (to run on the server over
> ssh when the local machine does not have hotwire installed.  For
> parallels you could look at xterm, gnome-terminal, konsole, cygwin ...
> which all provide ways of using terminals inside a gui window.

I have some more thoughts on the topic of API/code reuse and
frontends, and have actually been prototyping out something new...I'll
hopefully get it working and post it soon.