widget tutorial

[John Asmuth]

Tutorial on putting together a new widget: https://github.com/skelterjohn/go.uik/blob/master/widgettut.md

Give it a look, see if anything seems stupid.

[André Moraes]

Tutorial on putting together a new widget: https://github.com/skelterjohn/go.uik/blob/master/widgettut.md

Why in the 

func (r *Radio) HandleEvents() 

instead of a select on N channels not writing it as a type switch in one channel.

for {

  t := <-r.Events

  switch t.(type) {

    case UserEvent:

      r.HandleEvent(t)

    case []string:

      r.makeOptions(t)

    case int:

      r.select(t)

  }

}

Then, the only exposed object is r.Event reducing the external API of the object making it easier to use (I think).

[Michael Schneider]

Tutorial on putting together a new widget: https://github.com/skelterjohn/go.uik/blob/master/widgettut.md

Wow, very comprehensive!  Thanks for taking the time to write that up! 

[John Asmuth]

The reason for that is because the flow of some kinds of messages is different.

For user events - mouse clicks, key strokes - the flow is such that they need to arrive in-order, but if the widget is misbehaving (blocking for a really long time), it's ok to start dropping events. The user might get annoyed at having to redo things, but will only be annoyed at that one widget, since nothing else will get blocked.

For configuration data - the options and selection - it is unacceptable for the widget to drop messages. It would be a pain to have to check, in code, whether or not it successfully got the message.

For placement notifications - telling the widget who its parent foundation is and what its size is - the widget only cares about the very last placement notification that was sent. That channel is "stackable". That is, there is only ever at most one value waiting to be read, and it is a function of all values sent since the last read. In this case that function is "just the last one".

There are also a few channels that go from child to parent - size hints, invalidations, maybe some others - and they are also stacked (in different ways).

In summary, it might simplify the API a bit, but it would change the semantics of some of the message passing.

It would be nice to have some of these extra channels get thrown to a default case without writing them in, but I don't see a nice way to do that without changing the message semantics. My ears are open, though :)

- John

[André Moraes]

Using one channel for each flow, so:

User events -> can be dropped

Configuration events -> never dropped

Placement -> only the last

Flow foo -> foo behavior

Flow bar -> bar behavier

And then, on each of these channels the user can do a type switch.

func (r Radio) HandleEvents() {

  for {

    select {

      case ue <- r.UserEvents:

        r.handleUserEvent(ue)

      case config <- r.ConfigEvent:

        r.handleConfigEvent(config)

      default:

        // no ideas here too.

    }
  }

}

func (r Radio) handleConfigEvent(ev ConfigEvent) {

  switch ev.Data.(type) {

    case int: r.select(ev.Data)

    case []string: r.makeOptions(ev.Data)

[John Asmuth]

This is a good idea for events coming in. And, to a large extent, it's what I'm already doing. The problem with config events is they have to be outgoing, as well, and we can't do a type switch there.

I have a feeling that I'll eventually give in and add .GetX() and .SetX() methods that will send and recv on those config channels, but there's no reason to jump the gun while in the experimental stage.

[Anthony Starks]

Any particular widgets you'd like to see first?  Perhaps those that can build the proposed Go IDE?

On May 15, 2012, at 11:47 PM, John Asmuth wrote:

Tutorial on putting together a new widget: https://github.com/skelterjohn/go.uik/blob/master/widgettut.md

Give it a look, see if anything seems stupid.

--
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/-/jfM6_-SlGxkJ.
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.

[John Asmuth]

I think we should have a more modest goal.

A way I think to both generate interest (and, therefore, contributors) and still have good milestones is a list of ever-more-complex projects.

But it'd be nice if they were *useful* projects, and not just demonstrations.

What about an interface to the go tool? List the gopaths, their targets, and provide some buttons for doing the various operations the go tool likes to do. The arguments would be the currently selected targets.

[Anthony Starks]

I agree.  An interface to the Go tool is fine.  

[Anthony Starks]

the interface to the Go tool -- this is what your mockup was, right? 

On May 16, 2012, at 6:58 PM, John Asmuth wrote:

[John Asmuth]

The mockup was supposed to be for the whole IDE

[John Asmuth]

What do you think about this? http://dl.dropbox.com/u/4564102/go.uik/gotool.png

On Wednesday, May 16, 2012 7:14:11 PM UTC-4, Anthony Starks wrote:

I agree.  An interface to the Go tool is fine.  

On May 16, 2012, at 6:58 PM, John Asmuth wrote:

I think we should have a more modest goal.

A way I think to both generate interest (and, therefore, contributors) and still have good milestones is a list of ever-more-complex projects.

But it'd be nice if they were *useful* projects, and not just demonstrations.

What about an interface to the go tool? List the gopaths, their targets, and provide some buttons for doing the various operations the go tool likes to do. The arguments would be the currently selected targets.

On Wed, May 16, 2012 at 6:47 PM, Anthony Starks <ajst...@gmail.com> wrote:

Any particular widgets you'd like to see first?  Perhaps those that can build the proposed Go IDE?

On May 15, 2012, at 11:47 PM, John Asmuth wrote:

Tutorial on putting together a new widget: https://github.com/skelterjohn/go.uik/blob/master/widgettut.md

Give it a look, see if anything seems stupid.

--
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/-/jfM6_-SlGxkJ.
To post to this group, send email to go-...@googlegroups.com.

To unsubscribe from this group, send email to go-uik+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/go-uik?hl=en.

--
You received this message because you are subscribed to the Google Groups "go-uik" group.
To post to this group, send email to go-...@googlegroups.com.

To unsubscribe from this group, send email to go-uik+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/go-uik?hl=en.

--
You received this message because you are subscribed to the Google Groups "go-uik" group.
To post to this group, send email to go-...@googlegroups.com.

To unsubscribe from this group, send email to go-uik+unsubscribe@googlegroups.com.

[John Asmuth]

On Wednesday, May 16, 2012 11:34:36 PM UTC-4, John Asmuth wrote:

What do you think about this? http://dl.dropbox.com/u/4564102/go.uik/gotool.png

A lot of things to do here - scrolling, a slidable divider, tree view, a text area (though it is not editable, which makes it quite a bit easier). 

[Anthony Starks]

looks like a good start.  

One thing to consider: if you use horizontal position to indicate level, we can remove the triangle things.

also, what do the colors mean?

The arrangement of the top buttons should reflect the common workflow:

get, install, build, test, clean, fmt, fix

To view this discussion on the web visit https://groups.google.com/d/msg/go-uik/-/ybkoCe38ubcJ.

To post to this group, send email to go-...@googlegroups.com.

To unsubscribe from this group, send email to go-uik+un...@googlegroups.com.

[John Asmuth]

But atm they are how you'd expand a part of the tree. Clicking on [github.com/skelterjohn/go.wde/...] wouldn't expand that subtree, it'd *select* that subtree for targetting by the go command.

[Michael Schneider]

What do you think about this? http://dl.dropbox.com/u/4564102/go.uik/gotool.png

Looks like a worthy goal, boss!  Wanna assign me a widget to work on? 

[John Asmuth]

The tree makes use of a toggle-button. That is, a button that acts more like a checkbox, and draws differently when "on". Want to try that? Something simple so you can ease into the currently somewhat rough API.

[John Asmuth]

I made a nice tool to help with testing: https://github.com/skelterjohn/rerun

You tell rerun you want to work on a binary by specifying its whole GOPATH (like in the rerun readme), and it will auto-build and launch it for you. Useful when you're not sure exactly why your widget isn't working, and you want to quickly try a bunch of things and get instant feedback. With rerun in the background, just save the source file and it will kill the old program before running the new one.

On Thursday, May 17, 2012 10:10:25 AM UTC-4, Michael Schneider wrote:

[Michael Schneider]

The tree makes use of a toggle-button. That is, a button that acts more like a checkbox, and draws differently when "on". Want to try that? Something simple so you can ease into the currently somewhat rough API.

Sounds good.  I'll dive in.