GUI for GO

[huvber]

There is, or there is in project any package to create and managed a
simple grafical gui. In gtk or qt or wxwidget or another new graphics
interface?

[LizardFoot]

I imagine that there will be soon, but it will be completely new.
There are rumors of a Google OS lately. The OS is supposed to be
linux based with a new window manager.
It this happens, you can expect that the packages for Go will be
released with it.

[Jason Catena]

I recommend Acme, the Plan 9 tiled shell/editor window manager
(http://acme.cat-v.org/ has Rob's paper). After compiling Go for your
machine, they work together as well as any command-line tool. It's
most accessible (integrated with your host OS) in Plan 9 from User
Space (Russ Cox' unixy distribution of Plan 9, at
http://swtch.com/plan9port/).

Jason Catena

[TerryP]

Don't you think it's a little _s_o_o_n_ for that yet?

If Go is a success, most likely you will see GTK+, Qt5, and WxWidgets
bindings, probably even a Tk package, but all in good time! Should it
flop and fail to become a popular language, well crapola. If a GUI is
that important, might I suggest you get crackin' on doing it?

--
TerryP
Just Another Computer Geek

[smosher]

Most GUI toolkits use callbacks (and most are in C++ to boot) so it
makes implementing bindings a little difficult at the moment.

Someone built an SDL package (though I'm not sure how complete it is)
and I believe Xlib can be useful without callbacks. On the other hand,
implementing a GUI (or more specifically, building a GUI toolkit) in
either would not be pleasant.

[Dr. David Alan Gilbert]

* smosher (dark.n...@gmail.com) wrote:
> Most GUI toolkits use callbacks (and most are in C++ to boot) so it
> makes implementing bindings a little difficult at the moment.
>
> Someone built an SDL package (though I'm not sure how complete it is)
> and I believe Xlib can be useful without callbacks. On the other hand,
> implementing a GUI (or more specifically, building a GUI toolkit) in
> either would not be pleasant.

I wonder about running a GUI in another thread/process linked via
a pipe pair, with those pipes being terminated in channels.
So you would have:

1 goroutine that reads from a channel and writes it to a pipe
1 goroutine that reads from the pipe and writes it to a channel
1 goroutine that does all GUI stuff, it binds to the C gtk+, it
selects on the pipe (as well as X events) and reads commands from it;
when there is an event it writes a message on the pipe describing the event.

Then the main program has a main select statement that waits on the
channel from the GUI and receives events. If it wants to do anything
it writes commands up the pipe that do the actual GUI calls.

In a way this could be done as an external C program, although doing it this
way means it is the same memory space and you might be able to do something
special for images; it would probably be a fair chunk of work to define
the channel language unless it could somehow be almost automated.

Dave

--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/

[dark nowhere]

My first thought was to provide the callback handlers in C which
simply fill event buffers. Another call could then be used to poll the
buffers, and wrap those in go (i.e. do not expose the callback stuff
to go) as go wrappers that fill event channels. I haven't thought it
through and I suspect there are a few problems dealing with unhandled
buffers that would need to be paid attention to, but I suspect it
would probably work fairly well if you were careful.

On the other hand, it would be really nice to be able to interface
go's channels directly into C callbacks. C might not be happy about
interfacing with go's memory, but a channel filler could use a special
library call (i.e. one provided by the go package for the purpose) to
talk to the channel. Then the callback wrapper could simply talk to
the channel instead of resorting to filling a buffer that needs
polling. (Of course the channel still needs babysitting, but that's
more go-like.)

Either way, you still have the problems inherent to asynchronous
callbacks. They've never caused me trouble in C, but I wonder if that
might change when shoved down a channel in go.

[Adam Sampson]

"Dr. David Alan Gilbert" <da...@treblig.org> writes:

> I wonder about running a GUI in another thread/process linked via
> a pipe pair, with those pipes being terminated in channels.

Fred Barnes and some of his students have experimented with this,
although I don't think the last round of work on it is on the web yet:
http://frmb.org/rapp.html

It may also be worth looking at the GUI bindings in JCSP (our CSP-style
concurrency library for Java), which use a channel interface to replace
callbacks. They're available as part of the JCSP distribution:
http://www.cs.kent.ac.uk/projects/ofa/jcsp/

--
Adam Sampson <a...@offog.org> <http://offog.org/>

[Dr. David Alan Gilbert]

* Adam Sampson (a...@offog.org) wrote:
> "Dr. David Alan Gilbert" <da...@treblig.org> writes:
>
> > I wonder about running a GUI in another thread/process linked via
> > a pipe pair, with those pipes being terminated in channels.
>
> Fred Barnes and some of his students have experimented with this,
> although I don't think the last round of work on it is on the web yet:
> http://frmb.org/rapp.html

It's not obvious to me what the point of the 'server' in that is;
Can't you just talk to rapp-gtk via TCP?

> It may also be worth looking at the GUI bindings in JCSP (our CSP-style
> concurrency library for Java), which use a channel interface to replace
> callbacks. They're available as part of the JCSP distribution:
> http://www.cs.kent.ac.uk/projects/ofa/jcsp/

[quantumeer]

I just bound gtk-server using its shared library interface and cgo.
There is only one function: you just send and receive strings
according to the channel language that gtk-server defines, see
www.gtk-server.org Presumably, you could also use the pipes, sockets
etc interfaces that it provides as alternatives.

It seems a neat solution, so long as you don't mind a bit of string
wrangling.

Mark

[Dr. David Alan Gilbert]

Ah that is exactly what I was thinking would be a good way to do it.

[shinjikun]

I'll make a plug-in on eclipse...

I am makin' it at once - but only with syntax coloring or some other
easy stupid things, not very powerful.

Will that be needed?

On 11月19日, 上午9时32分, "Dr. David Alan Gilbert" <d...@treblig.org> wrote:

[MIURA Masahiro]

On Nov 16, 5:39 am, Jason Catena <jason.cat...@gmail.com> wrote:
> I recommend Acme, the Plan 9 tiled shell/editor window manager

> (http://acme.cat-v.org/has Rob's paper).  After compiling Go for your

> machine, they work together as well as any command-line tool.  It's
> most accessible (integrated with your host OS) in Plan 9 from User
> Space (Russ Cox' unixy distribution of Plan 9, athttp://swtch.com/plan9port/).

I have never used the real Plan 9, but had good experience using
an Acme clone called Wily, whose author is apparently on this group.

Off topic: I suspect that Go's formatting standard (hardtab
indentation,
no line length limit) is tailored to fit editors using variable-width
fonts, such as Plan 9 editors Sam and Acme.

[Kenji Okamoto]

> I have never used the real Plan 9, but had good experience using
> an Acme clone called Wily, whose author is apparently on this group.

Russ announced 9vx a while ago.
At that time, I wondered why he did it. However, I know now
he needed Plan 9 circumstance on linux to develope Go Lang...
I'll follow him.

Kenji

PS. sorry echochamber I replied to you person.