Actor-Based Widget Toolkit?
wookietreiber
I've been pondering on the idea for quite a while now -- has anyone ever
tried to design a widget toolkit based on actors? Is there any place
where thoughts about the matter have been gathered to figure out whether
the idea is worth considering?
Finally, anyone interested in writing a specification for an actor-based
widget toolkit and maybe implementing it using scala and akka?
--
Beste Gr��e / best regards
Christian Krause aka wookietreiber
Bernd Johannes
Am Donnerstag, 1. März 2012, 11:23:57 schrieb wookietreiber:
> Hi,
>
> I've been pondering on the idea for quite a while now -- has anyone ever
> tried to design a widget toolkit based on actors? Is there any place
> where thoughts about the matter have been gathered to figure out whether
> the idea is worth considering?
>
> Finally, anyone interested in writing a specification for an actor-based
> widget toolkit and maybe implementing it using scala and akka?
Hi Christian,
I don't know exactly what you envision - but I am currently writing a little wrapper thingy around SWT which allows me to interact with akka without much hassle.
The GUI part looks like this: (I borrowed the idea of a "path" from akka,
so every gui element has a name and an implicit path which is used to
address it "from the outside" - I know this can be a refactoring nightmare
when the GUI is redesigned but I was so appealed by the ease of addressing
that I implemented it)
--- ... excerpt from GUI construction code
// bottom panel
addAt(grid(10, 1)) {
new Composite("bottompanel", BORDER) with GridLayouter {
columns = 9
addAt(grid(1, 1)) {
new Button("play", PUSH) {
enabled = false
actOn(WidgetSelected) {
akkabridge ! ControlMessage.Start
true
}
}
}
addAt(grid(1, 1)) {
new Button("stop", PUSH) {
enabled = false
actOn(WidgetSelected) {
akkabridge ! ControlMessage.Stop
true
}
}
}
... -----------
Calling from SWT to akka is straightforward (see above).
Calling from akka to SWT is also possible and looks like that:
---- excerpt from akka bridge code
def fileload(filename: String) {
... some uninteresting stuff...
widgetExecute[Button, Boolean]("/shell/bottompanel/play", true)(enableControl)
widgetExecute[Button, Boolean]("/shell/bottompanel/stop", true)(enableControl)
}
// the type parameters are only required because enableControl() is generic
// if the function is explicit it just looks like that:
// widgetExecute("/shell/centralpanel/canvas", status)(drawCursor)
----
The only special thing is, that I have to manage a thightly coupled twin thread (the akkabridge thread and the SWT thread) which interfaces to both worlds. Maybe there are way cleverer solutions but I initially didn't find a way to merge the event loop of SWT with the akka event loop itself - so I resorted to this bridged solution.
So the bridge actor is the GUI proxy toward akka. Additionally an (optional) SWT worker thread can be employed to do "background" drawings which need more time and would block the GUI. However that worker is not allowed to interact with the GUI directly - it's only purpose is to create calculation expensive images which are forwarded (when ready) by the bridge to the GUI to be displayed.
This is all pretty much experimental and in its beginnings (but the code above is already working). I am doing this stuff to learn akka (and a little more scala by the way) in my spare time - so the progress is slow (in stark contrast to the akka team progresses :-).
And I wouldn't call it "toolkit" because I just try to smooth SWT a little toward scala (and enhance type safety) and provide some glue towards akka.
My experience with akka so far is fantastic (from 0 to Some(result) in almost no time!) and I prefer SWT over swing for a number of reasons although resource management is a nightmare sometimes. But all the existing SWT wrappers I tried somehow didn't do it for me. So I decided to reinvent the wheel again and learn something by the way.
To be honest I don't expect that there will be any interest in yet another SWT wrapper (albeit with a little akka glue). So I started this in the mindset of a private tool project. But we will see... :-)
Greetings
Bernd
G J
the experience was interesting.
warning: this does not address the question in this thread...; but,
has more to do with the Scala Swing library itself.
Akka was streaming in values from multiple places into a Scala-based
Swing GUI. This worked fine for simple GUIs, but anything beyond that
was a royal pain.
I eventually used the Java generated Netbean design, and integrated
that with Scala and Akka. Even though it is necessary to go back and
forth - massaging the generated Java code - it's a lot easier than
writing this stuff in Scala direct.
So, something that I would consider really worth it, is a modification
to netbean design that made it easy to integrate with scala. [Netbeans
is tight fisted about what it exposes, makes abstract, etc.] Or
perhaps a better netbean that makes use of Akka and Scala...
2cents.
On Mar 1, 5:23 am, wookietreiber <kizkizzbangb...@googlemail.com>
wrote:
Loren Schlomer
Integrating Qt Jambi with scala/akka has proven quite rewarding.
Mixing Qt's slots/signals with actor message passing makes executing
background tasks painless while keeping the UI snappy.
Plus, the Qt API is pretty much awesome.
The only downside is Jambi no longer has Nokia/Trolltech support and
the community development moves so slow it often feels like an
abandoned project, which is really sad.
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>
Alexey Romanov
wookietreiber
I thought more about an actor-based design from scratch - no wrappers or
the like. I would want it to be fully scala/akka-idiomatic, i.e.:
Model should be type-safe (not like swing, which, iirc, presents a lot
of java.lang.Object and java arrays) and should be accessible via an
interface that provides immutable data structures that easily can be
used as actor messages to both change and query the model
View should be pluggable (that is another matter anyway, but I would
definitely want it to support GUI, TUI, WebUI, accessibility, ...)
painting could be done like that:
class Painter[W <: Widget] { ... } extends Function[W,View]
class MyFancyLabel extends Label {
val painter = new Painter[MyFancyLabel] { ... }
}
the View can then use the painter as some sort of "guideline" how to
actually present stuff to the user (TUI just foreground on
background, GUI can also show a picture, WebUI includes an img tag,
...)
Controllers are actors (don't know whether standard or typed makes for
better usability vs. performance), i.e. Widget extends Actor { ... }
With akka 2+ maybe have an ActorSystem specifically for UIs, that uses a
dispatcher that has only one thread - if you've heard of [Multithreaded
toolkits: A failed dream?][1] ... I'd be very careful with that topic
...
... this is why I would try to carefully design such an actor-based
widget toolkit and most definitely do it collaboratively ;)
So far
[1]: http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
On Thu, Mar 01, 2012 at 09:43:27PM +0100, Bernd Johannes wrote:
--
Beste Gr��e / best regards
Christian Krause aka wookietreiber
---------------------------------------------
heute schon gelacht? >>> http://www.totaberlustig.com/comics/2011-11-17-Zeit.jpg
Bernd
from scratch.
I decided to use/wrap SWT as I am more or less pleased with the
performance and general behaviour.
By implementing widgets as actors you could send messages directly to
a widget or receive messages directly. That would isolate each widget
in an actor fashion.
But I think this is not the best approach for classic GUIs.
There are many situations which require that an action on a widget
leads to state change of several other widgets. It's normal and
natural to act on the other widgets directly within the acting widgets
action implementation. I feel like adding indirection here by using
messages to actors makes things more complicated and at the same time
solves nothing.
Thats the reason why I thought about the bridging between akka and
SWT. There are roughly following kinds of actions:
* User triggered GUI events which stay within the GUI
* User triggered GUI events which are propagated into the application
* Application actions which are propagated to the GUI
I think it's ok to have a GUI event thread which handles all the GUI
stuff. Ideally that would already be an actor - that's what I failed
to achieve. Therefore I bundled the GUI-thread with an akka-actor
thread which serves as communication hub between the GUI and the rest
of the actor system. That's not beautyful, but it works.
But I don't see the benefits of dissolving the GUI into a bunch of
actors.
But that's just me - there might be reasons I don't see right now.
Greetings
Bernd
On 8 Mrz., 00:09, wookietreiber <kizkizzbangb...@googlemail.com>
wrote:
wookietreiber
> I guess it's not a small task to rebuild a complete widget toolkit
> from scratch.
I think so, too. I have taken the liberty to start a project on github
[1] already containing a wiki [2] for collaboratively writing a
specification [3] for an actor-based widget toolkit. Feel free to
contribute ;)
[1]: https://github.com/wookietreiber/actor-wt
[2]: https://github.com/wookietreiber/actor-wt/wiki
[3]: https://github.com/wookietreiber/actor-wt/wiki/Specification
> I decided to use/wrap SWT as I am more or less pleased with the
> performance and general behaviour.
I thought about wrapping for the initial implementation, too, i.e.
wrappers for both Swing and SWT. But that would only concern the view of
the MVC pattern. The controller API should already be actor-based and
the model should already be more immutable-oriented.
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--