GotX: GUI Toolkit in the GO way

3,629 views
Skip to first unread message

frm

unread,
Jan 8, 2010, 2:14:38 AM1/8/10
to golang-nuts, nige...@golang.org, tor.an...@gmail.com
GotX is a GUI toolkit in the GO way???

See that question mark, GO way???
I still need to figure out which or what way is the GO way.

One suggestion that came up to my thought is the rule in
http://golang.org/doc/GoCourseDay3.pdf

"Do not communicate by sharing memory.
Instead, share memory by communicating."

So, I choose to use channel to implement the event handler / callback
mechanism.

Some features to consider:
- It uses channels to implement event handler.
- Can be used in synchronous or asynchronous manner.

Jackman

unread,
Jan 8, 2010, 3:31:43 PM1/8/10
to golan...@googlegroups.com
On Fri, Jan 8, 2010 at 12:14 AM, frm <frm.ad...@gmail.com> wrote:
> GotX is a GUI toolkit in the GO way???
>
> See that question mark, GO way???
> I still need to figure out which or what way is the GO way.
>

I assume you've already seen the following?:
http://www.youtube.com/watch?v=HmxnCEa8Ctw

--
Andrew Jackman
kd7...@gmail.com

CONFIDENTIALITY NOTICE: This e-mail message, including any
attachments, is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized
review, use, disclosure, or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message. All your base are belong
to us.

Bob Cunningham

unread,
Jan 8, 2010, 8:37:36 PM1/8/10
to golan...@googlegroups.com
On 01/08/2010 12:31 PM, Jackman wrote:
> On Fri, Jan 8, 2010 at 12:14 AM, frm<frm.ad...@gmail.com> wrote:
>
>> GotX is a GUI toolkit in the GO way???
>>
>> See that question mark, GO way???
>> I still need to figure out which or what way is the GO way.
>>
> I assume you've already seen the following?:
> http://www.youtube.com/watch?v=HmxnCEa8Ctw
>

Wow.

The power series example in the video led me to jump to the list of
papers and read them, after which a quick search led me here:
http://golang.org/test/chan/powser2.go, which then made me go read the
papers again.

This approach to power series has a very "fundamental" feel to it: Has
anyone pinged Don Knuth to consider adding this to an update to his
series? It needs to be made *very* easy to find.

Welcome to Go University. My brain hurts.

Now I need go to back to the window system example in the video and
think more about using sets of typed channels as "interfaces". More
brain strain pain.


-BobC

frm

unread,
Jan 8, 2010, 11:59:12 PM1/8/10
to golang-nuts
Thanks. I cannot watch the video, I have a very limited bandwidth.
But I've read the Rob Pike paper about Concurrent Window Systems, and
yes it uses channel
to implement the event handler.

These are my initial ideas
- The X protocol binding must use channels to communicate the events,
replies, and errors
to the client (GotX)
- GotX must handle events, replies, errors in a concurrent way,
but users must still able to use it sequentially
- The event handlers should be able to communicate with each other (by
means of channels)

I'm expecting respond

On Jan 9, 3:31 am, Jackman <kd7...@gmail.com> wrote:

ygl

unread,
Jan 10, 2010, 1:05:11 PM1/10/10
to golang-nuts

On Jan 8, 8:59 pm, frm <frm.adipu...@gmail.com> wrote:

> These are my initial ideas
> - The X protocol binding must use channels to communicate the events,
> replies, and errors
>   to the client (GotX)
> - GotX must handle events, replies, errors in a concurrent way,
>   but users must still able to use it sequentially
> - The event handlers should be able to communicate with each other (by
> means of channels)
>

it will be great to see a gui toolkit in the tradition of plan9's
libcontrol lib (http://plan9.bell-labs.com/magic/man2html/2/control).
controls has their own thread and manipulated thru channels, so gui
widgets are really active objects (actors:). i first read about it
from here (http://www.cs.unibo.it/ersads/tutorials/mullender.ps). my
initial reaction is "a thread for each widget? what is the overhead!",
now i am gradually wrap my mind around this. in fact recently JCSP did
the same thing to Java swing gui (http://www.cs.kent.ac.uk/projects/
ofa/jcsp/jcsp-1.1-rc4/jcsp-doc/org/jcsp/awt/package-summary.html)

hong

unread,
Jan 10, 2010, 2:32:35 PM1/10/10
to golang-nuts
> See that question mark, GO way???
> I still need to figure out which or what way is the GO way.

One thing to consider is GUI system needs to attract large
number of developers (see HTML, Flash, iPhone) and many
of them have different background and experience comparing
to system developers. The user experience and developer
experience is far more important than implementation details.
This will be my top suggestion on this topic.

Personally, I like to see the following features in the GUI kit:

* a simple and powerful UI description language, probably
based on html/html5, see webOS Mojo and Flash. Visual
Basic and Windows RES files are previous generation. The
idea is most GUI should be done by designers using
description language instead of by developers using
source code.

* i18n is a big cost in GUI comparing to system development.
Having intrinsic support will be very helpful for many people.

* a simple and extensible event model. Mac OS X and BeOS
have simple event system (comparing to Java). All you need
is one generic event type and one way to event dispatching
system, like addLister(objectId, eventId, listener) and
removeListener(objectId, eventId, listener), not bother with
addKeyEventListener(), addMouseEventLister() etc. Overtime,
there will be thousands of events, such as locale change,
time change, timezone change, network change, shutdown,
password change .... Doing it in Java style will end up
thousands of new classes and new methods.

* batch, batch, batch. In a typical GUI system, client receives
one event, processes it and send over many drawing commands
to server. These drawing commands must be batched together
for better performance. On local hardware, the batch of
commands can be sent to GPU hardware directly for maximum
efficiency. On remote server, you can easily send thousands of
operations to an HTTP server in a single request and have good
latency. This idea was done 2 decades ago with News system
(based on display postscript).

* Remote transparent and good scalability. Make sure the
system works well on local system (like game console when
most of GUI is handled by hardware) and remote system
(X like with large display and limited bandwidth, say NX).
Future GUI hardware will be much more powerful, say
games with 3000x2000 display with near movie quality
details plus 3D effects.

Instead of looking at low level concept, such as channel vs
shared memory, please also look at high level system, such
as iPhone vs webOS vs Android, PS3 vs Xbox vs Wii, OpenGL
vs OpenGL ES vs DirectX, ATI vs Nvidia architecture, touch
input vs keyboard and mouse.

Good luck.

Hong

Tim Kelsey

unread,
Jan 10, 2010, 3:03:45 PM1/10/10
to hong, golang-nuts
> Instead of looking at low level concept, such as channel vs
> shared memory, please also look at high level system, such
> as iPhone vs webOS vs Android, PS3 vs Xbox vs Wii, OpenGL
> vs OpenGL ES vs DirectX, ATI vs Nvidia architecture, touch
> input vs keyboard and mouse.

Hi,
I was also having some thoughts about a Go GUI, I actually come from a
games programming ( PS3/Xbox360/Wii/iPhone ect ) background and
couldn't agree more with hong. In particular with regard to a good GUI
description system. Be it XML ( Mozilla XUL style ), JSON or some
other system. I have lost many many hours building interfaces with
poor GUI tools, as one of the main goals of Go is a speedy and fluid
development experience, a good "Go GUI kit" should reflect this fact
as much as any technical or architecture idioms offered by the
language.

A good event broker system would seem like a good place to start,
components like this can also have a bigger scope than a single
project of course.

Alexis Shaw

unread,
Jan 11, 2010, 12:11:27 AM1/11/10
to golang-nuts
Why not use XML with a simplified CSS. In this way, people that are familiar with HTML can then make interfaces, also by using XSLT we can use existing browsers as a test bed.

frm

unread,
Jan 11, 2010, 2:11:57 AM1/11/10
to golang-nuts
Thank you, very constructive reponds.

I divide the features into 4 categories. I need more of your responds.

Core features
===========
Widgets are communicating by using channels, so each of them should
run in a different goroutine (consider the overhead)

Should support other windowing systems not only X


Features for widget developers (still thinking on it, your responds?)
========================
Simple event handler.
Simple creation of new widget types.


Features for GUI Application developers
================================
Developers should be able to define:
- Action that users can execute;
- Data that should be retrieved from the users;
- Data that should be displayed to the users;
- Application workflow.

Application developers are not forced to explicitly use a widgets, the
toolkit can automatically selects the best widget to use based on the
needed data and actions.

Features for GUI artists
===================
Using a common description system (maybe simplified CSS and HTML).
GUI artists should be able to define:
- GUI layout
- Widgets styles (look and feel, in Java terms)
- Force a widget to represents given data and/or actions


Looks like it will be a long and hard work. At least we know what
steps and on which way we should walk.
Do each steps in a small one but with eyes wide open.

Joan Miller

unread,
Jan 11, 2010, 7:17:36 AM1/11/10
to golang-nuts
There is a lot of people who hates XML (the XML configuration in java
world is a negative point where java has lost tons of developers).

In change, the technology that has released QT to build the user
interfaces is really cool!

http://labs.trolltech.com/page/Projects/Graphics/Kinetic/DeclarativeUI


On 11 ene, 05:11, Alexis Shaw <alexis.s...@gmail.com> wrote:
> Why not use XML with a simplified CSS. In this way, people that are familiar
> with HTML can then make interfaces, also by using XSLT we can use existing
> browsers as a test bed.
>

Devon H. O'Dell

unread,
Jan 11, 2010, 8:49:48 AM1/11/10
to frm, golang-nuts, nige...@golang.org, tor.an...@gmail.com
2010/1/8 frm <frm.ad...@gmail.com>:

> GotX is a GUI toolkit in the GO way???
>
> See that question mark, GO way???
> I still need to figure out which or what way is the GO way.

Go has a *lot* of foundation laid out in Rob Pike's Newsqueak
language, which was initially designed for implementing a GUI (which
eventually became 8 1/2, and then rio, in the Plan 9 operating
system). He mentions this in his tech talk at Google:
http://video.google.com/videoplay?docid=810232012617965344 (a very
good watch). I would imagine modeling something over those ideas would
be a good thing.

--dho

ygl

unread,
Jan 11, 2010, 10:25:36 AM1/11/10
to golang-nuts

On Jan 11, 5:49 am, "Devon H. O'Dell" <devon.od...@gmail.com> wrote:

> Go has a *lot* of foundation laid out in Rob Pike's Newsqueak
> language, which was initially designed for implementing a GUI (which
> eventually became 8 1/2, and then rio, in the Plan 9 operating

> system). He mentions this in his tech talk at Google:http://video.google.com/videoplay?docid=810232012617965344(a very


> good watch). I would imagine modeling something over those ideas would
> be a good thing.
>

i second this. even the markup/description based gui can work well
with chan/goroutine based design. inferno did this. basically its gui
toolkit use "tk" as its markup langauge, and, it plumbs gui events
from markup world back to programming world as channels (http://
doc.cat-v.org/inferno/4th_edition/limbotk/)

hong

unread,
Jan 11, 2010, 3:56:33 PM1/11/10
to golang-nuts
> i second this. even the markup/description based gui can work well
> with chan/goroutine based design. inferno did this. basically its gui
> toolkit use "tk" as its markup langauge, and, it plumbs gui events
> from markup world back to programming world as channels (http://
> doc.cat-v.org/inferno/4th_edition/limbotk/)

Please note chan/goroutine are very low level details. They hardly
matter in modern UI system design. Does anyone remember or
know or care how Windows/MacOS pass events? Almost nobody.

Hong

hong

unread,
Jan 11, 2010, 4:30:04 PM1/11/10
to golang-nuts
Some comments:

* Please define the term of "widget".

* Core features. Please keep it opaque UI to developers. If a GUI
needs
to write an event handler, he does not need to know the concept of
channel or goroutine or all the system programming details.

* Split markup and code cleanly. I like to see something like this
(in pseudo code):

// markup
<widget><button id="button1">Hello, World!</button></widget>

// code
widget.addListener("button1", "onclick", listener);

The idea is we don't embed source code into markup, such as
onclick="button1OnClick()" in html/js, and we don't need to
know button1 is a button in source code. The artist can change
button to another ui control and the code still works. Since
the markup is pure text, it can be easily translated for i18n
purpose.

* We must make sure the GUI system works fine with future
hardware. Current generation of graphics card has Teraflops
and 1GB memory. Most old GUI system can not take
advantage of them easily. For example, Mac OS makes
every window as a 3D rectangle and let GPU to compose
them together. Sending drawing operations directly to
hardware will be a huge win.

Anyway, this is a complicated feature, we need people
from different areas to join force.

Hong

Rob 'Commander' Pike

unread,
Jan 11, 2010, 4:31:43 PM1/11/10
to hong, golang-nuts

As you would see from the talk I gave, the idea is not about how to pass events around, it's about eliminating them altogether. It really is a different design. See also the research paper http://plan9.bell-labs.com/cm/cs/doc/89/1-a.ps.gz .

-rob


Hong Zhang

unread,
Jan 11, 2010, 5:20:36 PM1/11/10
to Rob 'Commander' Pike, golang-nuts
> As you would see from the talk I gave, the idea is not about how to pass events around, it's about eliminating them altogether. It really is a different design.  See also the research paper http://plan9.bell-labs.com/cm/cs/doc/89/1-a.ps.gz .

Event dispatching is a topic for system programming, but most UI developer cares more about how to implement specific event handler. BeOS uses one thread per window long time ago and Windows uses per-window procedure since day 1. Goroutine will handle it more efficiently, but I don't see it will change developer experience in fundamental way.

The deadlock in concurrent GUI system is a hard problem. Java community spent many years on it and finally gave up on it with Swing. The total time spent on it (back and forth) was huge.

Hong

Uriel

unread,
Jan 11, 2010, 5:30:30 PM1/11/10
to golang-nuts
On Mon, Jan 11, 2010 at 11:20 PM, Hong Zhang <ho...@google.com> wrote:
> The deadlock in concurrent GUI system is a hard problem. Java community
> spent many years on it and finally gave up on it with Swing. The total time
> spent on it (back and forth) was huge.

Apples and oranges. Java didn't use CSP, any kind of concurrent
programming without some form of CSP is most likely going to be a
pain, GUI or no GUI.

If you understand how Go (and Limbo and Alef, and Erlang, and ...)
work, you would realize that deadlocks don't need to be an issue at
all for concurrent GUI programming.

uriel

Uriel

unread,
Jan 11, 2010, 5:32:22 PM1/11/10
to golang-nuts
On Sat, Jan 9, 2010 at 5:59 AM, frm <frm.ad...@gmail.com> wrote:
> Thanks. I cannot watch the video, I have a very limited bandwidth.
> But I've read the Rob Pike paper about Concurrent Window Systems, and
> yes it uses channel
> to implement the event handler.

For those interested, here is Rob's paper on concurrent window
systems: http://doc.cat-v.org/bell_labs/concurrent_window_system/

uriel

Nigel Tao

unread,
Jan 11, 2010, 6:31:34 PM1/11/10
to golang-nuts
Traditional UI toolkits have an inheritance hierarchy: RadioButton
extends Button extends Widget extends Object.

Go has interfaces, but not inheritance. Does anyone know of UI
toolkits designed around composition, rather than inheritance?

Federico G. Benavento

unread,
Jan 11, 2010, 9:05:30 PM1/11/10
to ygl, golang-nuts
control(2) doesn't use a thread per widget/control, but it can use
a channel per widget.

the basic idea is that instead of using callbacks (or listeners ;)
you get a message from a channel.

--
Federico G. Benavento

ygl

unread,
Jan 11, 2010, 10:05:53 PM1/11/10
to golang-nuts

On Jan 11, 6:05 pm, "Federico G. Benavento" <benave...@gmail.com>
wrote:


> control(2) doesn't use a thread per widget/control, but it can use
> a channel per widget.
>
> the basic idea is that instead of using callbacks (or listeners ;)
> you get a message from a channel.
>
>

Thanks for the correction. my old post is inaccurate. Here is details
from man pages:
"A Controlset collects a group of Controls that share mouse and
keyboard. Each Controlset has a separate thread of control that
processes keyboard and mouse events as well as commands to be passed
on to the Controls."
"Controls are manipulated by reading and writing to the control
channel, ctl, of their Controlset"

hong

unread,
Jan 12, 2010, 12:29:13 AM1/12/10
to golang-nuts
> the basic idea is that instead of using callbacks (or listeners ;)
> you get a message from a channel.

I am perfectly fine with the idea. But if you look at classic
Windows GUI code, such as

while (GetMessage()) {
TranslateMessage();
DispatchMessage();
}

If you use one channel per window/widget, you will end up code
like this:

while (GetMessage(hWnd, &msg)) {
GetWindowProc(hWnd)(&msg);
}

The simplicity does not mean much to developers, since most
of them are busy dealing with the procedure itself, not the
standard event dispatching system. BTW, since we have one
channel per widget, it is better to get message from widget
directly, so we don't even need to expose the channel.

My argument is very few people care about above code. They are
part of GUI toolkit and it is the same for almost every application.
The hard part is how to dispatch the message after you get it.
Do you want people to write switch case, or if-else,
or virtual functions, or callback, or listeners, or whatnot?

Consider the standard html code, <button onclick="onClick()">,
developer writes the function onClick() and he does not care
who calls it, from what thread, through what channel, remote
or local. That is how most part of GUI should work. Or you
can look at game consoles to see how they deal with low
level graphics programming.

In my opinion, a successful GUI system should be designed
top down and make sure it covers every level well enough.
Mac OS X and iPhone is one example.

Hong

Federico G. Benavento

unread,
Jan 12, 2010, 2:20:35 AM1/12/10
to hong, golang-nuts
"but it can use a channel per widget."

or it can also use a single channel for all the
widgets, channels are variables, so you can
set and unset them.

--
Federico G. Benavento

Thaddée Tyl

unread,
Jan 12, 2010, 2:50:14 AM1/12/10
to golang-nuts
On Jan 12, 6:29 am, hong <h...@google.com> wrote:

> Consider the standard html code, <button onclick="onClick()">,
> developer writes the function onClick() and he does not care
> who calls it, from what thread, through what channel, remote
> or local. That is how most part of GUI should work. Or you
> can look at game consoles to see how they deal with low
> level graphics programming.

I need to agree with the above.

Furthermore, I've had an unprecise vision. The idea of using html+css
seems very welcoming for any gui programmer, as it takes away a lot of
layout configuration and harsh coding that we can find in usual gui
tools. That is one reason for the web to be that successful. Plus,
this idea seems only right from a programming language designed by
Google.

Additionally, we could have a http, or spdy-like protocol that
communicates between the gui and the back-end, Ajax-like. I might be
wrong, but using pre-existing javascript engines may help a lot,
possibly V8-based. Maybe we should leave the shiny facade to html, css
and javascript, and let Go truly be a systems programming language
that takes care of each apps' core.

html, spdy, V8, Go... this fairly feels like Google anyway!

Hong Zhang

unread,
Jan 12, 2010, 10:17:19 AM1/12/10
to Federico G. Benavento, golang-nuts
> "but it can use a channel per widget."
>
> or it can also use a single channel for all the
> widgets, channels are variables, so you can
> set and unset them.

If it can be either way, then it is not an important
design decision to worry about.

Hong

frm

unread,
Jan 12, 2010, 12:59:40 PM1/12/10
to golang-nuts

I only know toolkits that are designed by inheritance. I have some
ideas for GO toolkit.
Interfaces always describe about functions. So we should classified
the toolkit
components by what it does not what it is.

Input interface are components that accepting inputs from user (i.e.
mouse activity or keyboard activity)
Output interface are components that showing data to the user (just
like Label showing text)

If we combine the Input and output interface then we have a component
that accepting user input
while keeping user informed about its data. For example, TextField
component receives keyboard activity (or textual data)
and also show its currently data to the user. So textfield is an input
and output component.

Action interface are components that waiting user for input, but
instead of showing data as the result
it executes actions. Just like a button does.

So we have 3 categories of component interface: Input, Output, and
Action

If we do a sub classifying of those 3 categories, then it should be
classified by what type of data the component is working on.
For example, we know that label's output is a textual data (or string)
then we can say that it is a TextOutput interface.
We know that a slider input is mouse activity, and its output is a
numeric data (represented visually by the slider thumb position),
then we can say that a slider is a MouseInput and IntegerOutput
component.

If we take the above concept to a higher level, GUI developers are not
needed to specify the component UI, instead they need to
specify what is the input and the output.
Maybe GUI developers should code like this for a login window:

type LoginRequest struct {
Username string
Password string
RememberPassword bool
Login Action
}

var f Form
var msg TextOutput

func Main() {
f := FormFor(LoginRequest{})

// Make the password displayed as password character (i.e. *)
f.Child("Password").OutputAs("password")
msg = f.AddOutput("Enter username and password")
}

func (l LoginRequest) OnLogin() {
// check login
if checkLogin() { // correct username and password
// do some code
} else {
msg.Out("Incorrect username or password")
}
}

From the above code the toolkit should analyze the LoginRequest struct
to generate a default GUI.
The default GUI is a form with:
- text input/output for "Username"
- text input and password output for "Password"
- check box for "RememberPassword"
- label for displaying message
- button for "Login" action, when clicked it will execute OnLogin()

The generated form can be fine tuned (change the layout or visual
styles) using external files, maybe in HTML or CSS format.

frm

unread,
Jan 12, 2010, 1:28:24 PM1/12/10
to golang-nuts

You have an interesting vision.

For the next 5 or 10 years. If all the people do the GUI things using
HTML, CSS, and JavaScript,
do we still need a GUI toolkit? We only need a web browser, and there
are so many (or not so many) choices of great web browsers.
So YES we need a GUI toolkits, for running web browsers on top of it.
Then only web browsers that run on top of GUI toolkits. And today's
web browsers keep its decoration simple and minimal.

Maybe we should find what a GUI toolkit should provides other than
displaying user interface just as web browsers do.
Any ideas???

hong

unread,
Jan 12, 2010, 11:05:47 PM1/12/10
to golang-nuts
> Maybe we should find what a GUI toolkit should provides other than
> displaying user interface just as web browsers do.
> Any ideas???

3D games. However, people are moving more and more features
into browser to achieve the vision of "Browser is OS". I don't
know how much market is left outside browser.

One approach is to use Go to program browser DOM and extend
the DOM to do extra stuff, similar to webOS does today.

Hong

Don Paride

unread,
Jan 13, 2010, 7:53:28 AM1/13/10
to golang-nuts
http://harmful.cat-v.org/software/

Please, avoid harmful stuff!!!

On 11 Gen, 06:11, Alexis Shaw <alexis.s...@gmail.com> wrote:
> Why not use XML with a simplified CSS. In this way, people that are familiar
> with HTML can then make interfaces, also by using XSLT we can use existing
> browsers as a test bed.
>

Alexis Shaw

unread,
Jan 13, 2010, 8:14:21 AM1/13/10
to golan...@googlegroups.com
I do not want to get into a flame war, but, though HTML is hard to implement, it is not all that bad.
GUI designers do not want to have to be programmers or to learn new things, HTML would free them from this.
They already know how to use CSS, using it here makes sense.

Peter Bourgon

unread,
Jan 13, 2010, 8:24:11 AM1/13/10
to golan...@googlegroups.com
Are there any other frameworks that use HTML/CSS-style descriptions
for desktop application interfaces?

I see the idea bounced around here & other places but I don't know of
any already-existing examples.

Tim Kelsey

unread,
Jan 13, 2010, 1:31:04 PM1/13/10
to peter....@gmail.com, golan...@googlegroups.com
2010/1/13 Peter Bourgon <peterb...@gmail.com>:

> Are there any other frameworks that use HTML/CSS-style descriptions
> for desktop application interfaces?
>
> I see the idea bounced around here & other places but I don't know of
> any already-existing examples.
>

yes, Mozilla XUL. It uses XML/CSS/ECMA script for building desktop
apps like Firefox/Thunderbird/Song Bird.

https://developer.mozilla.org/En/XUL

Tim Kelsey

unread,
Jan 13, 2010, 2:12:40 PM1/13/10
to peter....@gmail.com, golan...@googlegroups.com
at the games company I work for our artists build interfaces with
flash, this is exported using a custom tool and then imported into the
code side. Its hooked up using events. I.E. a button click will send
out an event that many other code side actions will pick up on. This
has worked quite well, event based publish subscribe style systems is
something I find quite an effective means of breaking up "interface to
logic" or even "logic to logic" style problems. Often both the logic
and the interface can be reused in independent ways once built.

although we don't use it, a middleware package called "Scaleform"
(http://www.scaleform.com/) exists for working with flash in this way.
Its a popular package with a lot of AAA developers.

I'm not suggesting this is by any means a correct or even good way for
this sort of project to work, but using WYSIWYG tools like flash is
about as simple as it gets for the GUI builder. I'm not sure what the
status of any opensource tools similar to flash are, but hey, its one
more point in the discussion ;-).

Personally I'm not really a fan of HTML/CSS, but the idea of a
separate way of describing the structure of a UI to the way you
describe its appearance is a very sound way of working. It results in
a much more flexible and reusable UI and also allows for system wide
configurations to easily be applied uniformly over applications from a
single data source.

There are of course other description alternatives like JSON. This, as
pointed out by Don Paride, is less harmful.

hong

unread,
Jan 13, 2010, 3:32:02 PM1/13/10
to golang-nuts
> yes, Mozilla XUL. It uses XML/CSS/ECMA script for building desktop
> apps like Firefox/Thunderbird/Song Bird.

Mozilla uses XUL, Microsoft uses XAML, both are XML based.
webOS uses HTML/CSS, and it is beautiful, really beautiful
(however, it is very slow due to javascript and lack of optimization).
All of them can provide high quality desktop application interface.

Using HTML+CSS (similar to webOS) as UI description language
will be simpler choice given millions of people already know it and
we can add features as needed. It is probably much cheaper to
develop than inventing something from scratch like XAML.

In the end, this is just part of the whole picture. There will be a
lot of work to get every piece together.

Hong

frm

unread,
Jan 14, 2010, 12:24:43 AM1/14/10
to golang-nuts
Please define "Harmfull stuff".
We can avoid using harmfull stuff listed at http://harmfull.cat-v.org.software/
But we cannot avoid creating our own harmfull stuff if we don't know
what kind of software is a hamrfull one.

Thaddée Tyl

unread,
Jan 14, 2010, 2:10:03 AM1/14/10
to golang-nuts
Let's assume we're working for some secret agency that needs a program
to list all their agents, and possibly add one. The data is stored in
the harmless JSON format.

How would you like this code? The html file is left as an exercise to
the reader.

package main

import (
"gui"
"json"
"io/ioutil"
"os"
"strconv"
)

type Spy struct {
Name string
Age int
Mission string
}

func main() {
req := make(chan gui.Request)
resp := make(chan string)
gui.Open("welcome.html", req, resp)
for {
resp <- cgi(<-req)
}
}

func cgi(args map[string]string) string {
// file:///secret.html?name=OSS&age=117&mission=Antipode's Cabin
// Read file.
f, _ := os.Open("data.json", os.O_RDWR, 0)
defer f.Close()
b, _ := ioutil.ReadAll(f)
s := string(b)
// Parse file.
var spies []Spy
json.Unmarshal(s, &spies)
newSpies := make([]Spy, len(spies)+1)
for i, el := range spies {
newSpies[i] = el
}
age, _ := strconv.Atoi(args["age"])
newspies[len(spies)] = Spy{args["name"], age, args["mission"]}
f.Seek(0, 0)
json.Marshal(f, newSpies)
// Give all data back.
f.Seek(0, 0)
b, _ = ioutil.ReadAll(f)
return string(b)
}

hong

unread,
Jan 14, 2010, 3:07:34 AM1/14/10
to golang-nuts
I am not sure what you are talking about.

Go does not support any security model. It depends on process sandbox
for security protection. If you look at os.Stdout or unicode table.
They are all global variables and you can change them anyway you like.
You can also issue system calls directly and pass invalid buffer to
things like fcntl(). So I don't see your point here.

If we use security model similar to Android, each app has its own uid,
so they can only read/write data in the app's home directory. Cross
app communication is controlled by separate permission system. But I
don't think this issue is specific to GUI.

Hong

Tim Kelsey

unread,
Jan 14, 2010, 3:37:00 AM1/14/10
to hong, golang-nuts
2010/1/14 hong <ho...@google.com>:

> I am not sure what you are talking about.
>

This is my own interpretation and may differ to others.

Software is best kept as simple as possible. The simpler it is the
less potential for hidden ( or event deliberate ) errors to be hiding.
Thus we get more robust dependable solutions. Simple software will
also tend to run faster, no code is the fastest code ( not allays
strictly true, but more often than not ). Finally, and perhaps most
importantly for something small and new like Go, simple code is easy
to pick up and run with.

"Harmful Stuff" to my mind, is any technique/library/practice that
forces your code to be more complex than it really needs to be. If you
find that 90% of your code is for setup/teardown of something and only
10% is actually involved in the solving the problem at hand, then your
most likely using something harmful. In the case of a GUI, lets say
for example HTML/CSS is used to describe a single widget. The HTML
parser + DOM + CSS theming engine will likely be vastly more complex
than the code that actually creates and renders the widget.
Potentially this complexity could transfer to an application using the
GUI, and so on. In effect making the GUI itself harmful.

Im not sure about the specifics of the security example given before,
but the more painful the side effects of a code error are the more
harmful harmful stuff becomes.

Thaddée Tyl

unread,
Jan 14, 2010, 9:24:57 AM1/14/10
to golang-nuts
The case around harmful software is specifically targeted at monstrous
code in which a patient analysis can throw away half of it because of
redundancies. Obviously, when dealing with a GUI toolkit, which deals
inherently with a huge number of elements, let alone platforms, we are
very lucky if we do not become harmful. Hence GTK and Qt being listed
as harmful.

But harmful software is linked to another consideration: orthogonality
of tools. We need elementary tools whose purposes does not intersect.
And what do we need? Rendering, event handling, and the wiring between
the facade and the inner workings of the app. The problem is, to keep
this all easy and smooth, which is possible (http://www.youtube.com/
watch?v=waTL1abCm9I), we are not fast enough, we will have built
nothing more than an extensible skeleton by the end of 2010. People
want complex windows and widgets that have native look and feel. Maybe
we can do something else that is great, but maybe nobody cares about
something great if it doesn't fit in what is "the trend".

The good points about html are that it is getting more and more
popular, it is getting really app-like thanks to html5, and it is
widely supported. Plus, it helps to dissociate the appearance and the
heart of the app. The nasty points are that the standard (html5) is
unfinished, the rendering engines implement it poorly, and there are
as many javascript event handlings as there are user agents.

In the end, what really counts to me is that I can program the parts
of my app that really counts without thinking about how the app looks
like. The example of a simple data management app was an early
proposition of a such design.

Reply all
Reply to author
Forward
0 new messages