whacky

[Daniel Skinner]

Short and sweet, found myself with some free time, wanted to start writing an editor with go-uik (yeah yeah). But it's been one issue after another (and nothing against go-uik). So I pose, what's the biggest road block to something like this taking off?

To answer my own question, it seems like dependencies and API changes. To run over how uik works again, I went to compile example/uiktest but was met with an ugly error. I resolved that error to be met with another. I wiped everything clean (repo wise) and updated all the repositories with `go get -u all` and went to compile again, and yet again im running into issues with BurntSushi's xgbutil pkg accessing the draw2d freetype pkg incorrectly (API changes and such).

I know we all have things to do otherwise, (I certainly do) but what can we do about this? We need to get all developers and related packages to commit to an API, at least to a reasonable frame of time of a couple years or so. As it is, this is just discouraging to any wannabe and even more so to the experienced developer with only a bit of time to spare on something free and open.

Myself, I have to say that I'm more interested right now in seeing that commitment take place more than anything else. Screw my pet project, I'd like to see many things come about. But we're all busy, so what can we do to get other dev's that have put the time in to commit to an API so can all benefit from a package like go-uik which depends so heavily on these?

[John Asmuth]

Hi Dan,

Sorry it took so long to reply. I actually had this as a draft sitting around nearly since your original email.

One thing that will help with the commitment to go.uik is my upcoming completion of grad school. Right now I simply can't justify setting aside time for a pet project.

When I finish school, I'll be starting at google, and I intend to make go.uik my 20% project. Hopefully that will give some confidence in continued progress.

Regarding draw2d and burntsushi's xgb stuff, I'm thinking seriously about moving to an entirely opengl-based backend. The collection of go opengl packages is growing, and it's becoming easier to get them working cross-platform.

- John

--
You received this message because you are subscribed to the Google Groups "go-uik" group.
To view this discussion on the web visit https://groups.google.com/d/msg/go-uik/-/pdpo3Xg-8wwJ.
To post to this group, send email to go-...@googlegroups.com.
To unsubscribe from this group, send email to go-uik+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/go-uik?hl=en.

[Daniel Skinner]

Hi John,

Very understandable about pet projects. I use opengl with Go on linux quite successfully myself for play in exploring cellular automata and I was considering work on an opengl backend for go.uik as well. Just so busy and such.

I dont personally think it would be completely appropriate to ditch draw2d/xgb completely but perhaps provide an interface for drawing that could make use of different backends. And then I would have to agree that in this phase of things, it would be far more productive to focus on the opengl backend.

This might initially limit where go.uik could run, limited to graphic accelerated environments, but would greatly simplify the drawing process so a more concentrated effort could be made on providing a full set of features.

When the other packages come around, that just opens up more areas to run go.uik, but the focus really needs to be on uik, not keeping up with ever-changing packages.

I only vaguely keep up with the opengl stuff, and only partly familiar with go's threading model, but I do believe everything has to be locked to a single thread which works against the goals of go.uik. Here I'm referencing use of `github.com/chsc/gogl` package where one needs to issue a `runtime.LockOSThread()` if using goroutines.

In light of that issue, I still think it's worthwhile to pursue the opengl backend as its only a matter of time before go.uiks goals of a non blocking UI are eventually met.

Cheers,

Daniel

[John Asmuth]

Hi Dan,

Comments inline.

On Thu, Dec 6, 2012 at 11:21 AM, Daniel Skinner <dan...@dasa.cc> wrote:

I dont personally think it would be completely appropriate to ditch draw2d/xgb completely but perhaps provide an interface for drawing that could make use of different backends.

That is what go.wde (also my project) is intended to be. However, go.wde is raster-based, and all the copying of pixels around makes this naturally slower.

 

And then I would have to agree that in this phase of things, it would be far more productive to focus on the opengl backend.

This might initially limit where go.uik could run, limited to graphic accelerated environments, but would greatly simplify the drawing process so a more concentrated effort could be made on providing a full set of features.

Every system supports opengl, whether it's got a graphics card or not. The kinds of things that go.uik needs (2D) can be done quickly in a software driver.

 

When the other packages come around, that just opens up more areas to run go.uik, but the focus really needs to be on uik, not keeping up with ever-changing packages.

go.wde is supposed to isolate those changing packages, and it succeeds at doing that. Unfortunately that means someone has to be on the ball for each of those packages and update go.wde accordingly.

 

I only vaguely keep up with the opengl stuff, and only partly familiar with go's threading model, but I do believe everything has to be locked to a single thread which works against the goals of go.uik. Here I'm referencing use of `github.com/chsc/gogl` package where one needs to issue a `runtime.LockOSThread()` if using goroutines.

That's right, but drawing and event processing are handled separately.

In fact, right now all drawing is already done in a single thread. I was unable to create a system that could both draw correctly (that is, never display unfinished images on the screen) and quickly. That is not to say that one does not exist, or that I could not create one if I tried harder. But it's certainly not trivial.

The fact that the opengl packages require you to lock the thread would have no effect on go.uik's current architexture. The guarantees I make with regards to components not getting in each others' way apply only to event handling.

I tell myself that this half-guarantee is ok, because it's much easier for a component developer to write draw code that will never block than to write event code that will never block.

 

In light of that issue, I still think it's worthwhile to pursue the opengl backend as its only a matter of time before go.uiks goals of a non blocking UI are eventually met.

The have been met - the backbone is solid and working. The biggest things that need to happen next are (in no particular order):

- finalize the graphics backend, either with opengl or make some efforts to stabilize go.wde. In fact, I think it would be good to have go.wde/gl, which will allow you to draw to a raster image the same way the other backends do, and have opengl display it, and also give back events etc. When the gl backend is being used, the application should be able to safely make normal opengl calls.

- make the killer layout engine. Right now in the go.uik/layouts package I have a few examples. The most flexible is the grid, modeled after the GridBagLayout from javax.swing. But, frankly, it's terrible. The arithmetic required to get everything to be consistent with resizing, adding and removing new components, etc is difficult. I have something that can pack a set of components nicely once, but when things change there are no guarentees that the repack will line up nicely with what came before. I'd really like something like CSS, except not terrible and confusing. Something where you can give it a document configuration file, and a set of named components, and it will figure out where to put them. I've already set up an interface for this that should make it easy to integrate into go.uik.

- John

[Daniel Skinner]

All of that is great to hear :) These lower level details are a bit beyond me mostly out of interest.

- make the killer layout engine.

This was actually one of my interests in go.uik was working on this. But my results here would likely be not-so-stellar.

 

I'd really like something like CSS, except not terrible and confusing. Something where you can give it a document configuration file, and a set of named components, and it will figure out where to put them. I've already set up an interface for this that should make it easy to integrate into go.uik.

This is my main interest. I really enjoy writing DSLs and wanted to set something up to easily create layouts and styles. This might not be totally appropriate as the official go.uik way as it would be more suitable to make use of xml/json for programmer-familiarity and parsing with the encoding package would mean more time making a great ui toolkit for others involved. I'd work on this regardless though b/c I just enjoy this type of work.

First and foremost in my mind though, once there's a stable drawing backend implemented, I'd probably be hacking layouts, widgets, styling, animations, etc. Then I'd find myself wanting to declare a documents for layouts and bringing it all together for a text editor.

[John Asmuth]

On Thu, Dec 6, 2012 at 12:01 PM, Daniel Skinner <dan...@dasa.cc> wrote:

I really enjoy writing DSLs and wanted to set something up to easily create layouts and styles. This might not be totally appropriate as the official go.uik way as it would be more suitable to make use of xml/json for programmer-familiarity and parsing with the encoding package would mean more time making a great ui toolkit for others involved.

I'm 90% of the way to insisting on json. I'm 100% of the way to insisting that it be something that can be dumped easily into a go struct. Whatever layouting language is used, there should be no logic in there - just layout information. Logic needs to be written in go. 

 

First and foremost in my mind though, once there's a stable drawing backend implemented, I'd probably be hacking layouts, widgets, styling, animations, etc. Then I'd find myself wanting to declare a documents for layouts and bringing it all together for a text editor.

I really want to encourage you to think about how a nice document-based layout engine would work. Feel free to start a new thread for kicking around ideas.

 

[Daniel Skinner]

I'm 90% of the way to insisting on json. I'm 100% of the way to insisting that it be something that can be dumped easily into a go struct. Whatever layouting language is used, there should be no logic in there - just layout information. Logic needs to be written in go. 

I feel the same on JSON, and that missing 10% for me is some of the needless semantics that can cause dealing with silly errors. 100% agree on logic, I wouldn't even want to see anything like "onClick" that references a supposed function written in Go, dealing with stuff like this is the bane of my existence :p

 

I really want to encourage you to think about how a nice document-based layout engine would work. Feel free to start a new thread for kicking around ideas.

While I haven't used it, I really really liked QML http://en.wikipedia.org/wiki/QML b/c of the familiarity it brings with JSON-like syntax while side stepping silly problems like commas. This could even be accomplished with a preprocessor that makes the document json compliant and then just allows use of the encoding/json package.

I'm still likely to explore complete custom solutions as well out of personal interest and I'll throw around some ideas on a new thread one day when uik is at a point to actually benefit from this :)

[John Asmuth]

If you don't like some of json's weird spots, consider this: http://rogpeppe.wordpress.com/2012/09/24/goson-readable-json/

--

[Daniel Skinner]

nice! I'd have to look at the interface you mentioned previously but without too much regard to that, I'd picture a lexer interface that reads in the rjson and emits appropriately, and the previously mentioned interface would create the UI based on received tokens. Then could ease some alternative development for defining documents.

In the end though, I think I'd be of the opinion of removing the lexer interface (or never having it and just have a separate branch) and enforcing a single document style or risk segmentation between potential uik developers.

[John Asmuth]

Without addressing what you are saying about lexers too deeply, I believe you may be thinking about an already-solved problem. Rog's rjson package will take a document and use it to populate a go structure. That go structure should be the input to the layout engine - no lexing or parsing code need be written.

[Daniel Skinner]

I see, that completely side steps what I was thinking was needed.

[Dobrosław Żybort]

I have one idea/request when you start building it from scratch:
soon PC/Laptops will probably start getting higher resolution screens, so please think about adding support for auto resizing for bigger DPI.

Best regards

[John Asmuth]

When I resume dev (soon!) I am thinking real hard about making it opengl- and vector-based. This would take care of any DPI issues :)

Visit this group at http://groups.google.com/group/go-uik?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dobrosław Żybort]

Thank you for reply.

If you plan to implement list box widget would be nice to have OTB virtual mode for it. More how it works in Windows Forms ListView:
http://www.codeproject.com/Articles/42229/Virtual-Mode-ListView
http://geekswithblogs.net/akraus1/archive/2010/06/21/140545.aspx

Sorry if I request too much but I would like to have as good cross platform GUI as possible from the start :)
Would be great to have native Go GUI (fast and lightweight) supporting most of http://en.wikipedia.org/wiki/GUI_widget#List_of_common_generic_widgets

Best regards,
Dobrosław Żybort