Phase 1 goal

[John Asmuth]

Here's a goal: a go IDE.

I think that we should focus all widget and layout creation towards this goal, and I think this is a good time to start a discussion about what such an IDE may look like. I'll just leave an unordered set of ideas for people to comment on.

- Integration with the go tool (build, get, fmt, fix etc).

- Integration with VCS, to the extend that it can identify if a file is not committed or not pushed. Building a complete git or hg front-end is beyond scope.

- lightide-style contexts that show code for a top-level declarations (func, type, var, const) without showing the rest of the file.

- two-column editor: special-click on an identifier that matches another top-level decl and it brings it up in the right column.

- gopkgsearch-style code search. A text-entry at the top where you can type a partial indentifier and it will bring up a list of edit bubbles to expand. identifiers can be top-level decls, file names or perhaps even packages.

[Dang Allen]

How many platform will be supported? Windows? Linux? MacOS?

> --
> 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/-/POTiG2863moJ.
> 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]

It uses go.wde, which has a backend for X (linux, poorly on mac), Cocoa (nicely on mac) and just recently someone created a backend for windows, though I haven't tested it yet.

[John Asmuth]

I made a bit of a storyboard for the general flow I envision.

http://dl.dropbox.com/u/4564102/ide_storyboard.pdf

This shows what one might see immediately upon launching the IDE.

Not shown is how the search bar would work. As mentioned in the previous message, it'd work similarly to gopkgsearch. You type something in and it fuzzily-matches against all known import paths, file names and package-level declarations, and lists them in the left column. You can then click through with that as your starting point, instead of $GOROOT the set of $GOPATH workspaces.

Also not shown are some navigation niceties, like a "back" button and whatever else would be needed to navigate quickly.

Along with ctrl-clicking digging into the source, right-clicking can bring up a context-menu that has an item "documentation", that displays the godoc in another bubble.

Thoughts?

[Anthony Starks]

If we really want a Go-style IDE, I want to see a visualization of the GOPATH hierarchies.  I want to see actions occur in response to actions.  For example, if I go get ... I want to see files fill in, with indications of updates, I want to see .a updated in $GOPATH/pkg and binaries go in $GOPATH/bin

[Anthony Starks]

in the storyboard, what is the purpose of the blue rectangle on the top?

--
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/-/AGmwoUIeIsEJ.

[John Asmuth]

That is the search bar. Type in your partial query there and it goes to town.

- John

[AllenDang]

Will go-uik use wxwidget way (use native control) or Qt way (draw native look and feel) to support multiple platform?

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.

[AllenDang]

I think we should focus on creating a GUI designer first as go-uik is a GUI framework. Target a small and specific goal will increase the successful rate of a project.

[John Asmuth]

Neither. go.uik will look like go.uik on any platform.

[John Asmuth]

I don't understand how creating a GUI designer would be easier than an IDE...

[Dang Allen]

Problem is currently sublimetext2 + gocode + gosublime is good enough
for coding, but there is no any GUI designer. And a designer is
critical for GUI framework.

2012/4/28 John Asmuth <jas...@gmail.com>:

> --
> 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/-/L6o2BtfquMwJ.

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

> go-uik+un...@googlegroups.com.

[Dang Allen]

So, go.uik will be a DirectUI kind of thing?

2012/4/28 John Asmuth <jas...@gmail.com>:

>>> go-uik+un...@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+un...@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 view this discussion on the web visit

> https://groups.google.com/d/msg/go-uik/-/y_35tluyt_cJ.

>
> 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]

I disagree. If by "designer" you mean a WYSIWYG-style thing that builds code for you, or creates config files that specify layouts and widgets, that comes distinctly later. For now, building the UI in code will do.

And what you've got might seem "good enough", but that's just because you haven't seen what's better, yet.

As for DirectUI, I don't know much about that. It might answer your question to say that go.uik will use go.wde for (w)indows, (d)rawing and (e)vents, and go.wde just draws a raster into a window. go.uik will fill that raster the same no matter what platform it's on.

- John

[Michael Schneider]

John Asmuth, 

I'd love to join your team here.  I've worked with Qt for a few years and have been quite underwhelmed with it's behavior on Mac OS X.  I know several gophers thought a wrapper to existing toolkits is the answer.  Personally I've always found wrappers (like GTK and Qt) to be a buggier, less feature rich version of the native toolkit.  I applaud your efforts to write a toolkit from scratch.  I think this is a truly noble goal, one that not only allows us to let Go shine, but allows some creativity and innovation to shine as well.

That said, where do I begin?  Are you the commander and chief delegating responsibilities?  Or are you just taking pull requests as they come?  Just so you know where my strengths lie, I'm a web developer by trade, but I've actually written a full fledged text-editor in Qt, complete with theme-able syntax highlighting, dynamically can support any language, customizable tab-triggered and command driven snippets, fuzzy file finder, etc.  Also, although I love linux, I spend my full time work week on a Mac.  Maybe I could help with fleshing out the Mac side of the toolkit?  Just a thought...

[John Asmuth]

Hi,

Glad to hear of your interest!

Right now there is nothing formal. I'll look at pull requests people make and accept them as seems appropriate. But a nice thing about the "go get" ecosystem is that your code doesn't need to be in the same repository for things to work. This is why I put them in the local "widgets" and "layouts" packages - they have no special ability to look at the uik internals.

If you're thinking about "the mac side of the toolkit", that would be contained entirely within go.wde/cocoa. go.uik will know nothing about the platform it's running on.

One thing that I would like to have done in the near future is settle on a good way for go.wde to provide keyboard input. Right now it sends an int and a string, for the code and printable letter. For regular letter this works fine on all platforms. For special keys (delete, arrows, alt, things like that), each platform seems to have a different set of codes. I want something to filter this and send something uniform, and to also track key chords nicely. Any interest in this?

- John

[Michael Schneider]

One thing that I would like to have done in the near future is settle on a good way for go.wde to provide keyboard input. Right now it sends an int and a string, for the code and printable letter. For regular letter this works fine on all platforms. For special keys (delete, arrows, alt, things like that), each platform seems to have a different set of codes. I want something to filter this and send something uniform, and to also track key chords nicely. Any interest in this?

John, 

I wouldn't mind working on that.  However, it sounds like we have some design decisions to make first.  One idea I had is, since Go does everything utf8 by default, attempt to take advantage of that.  Instead of inventing yet another set of codes, could we do something like pass a utf8 arrow character for cursor keys (→, ←, ↑, or ↓).  I'm sure we could agree on appropriate symbols for shift, alt, control, and super as well.  This would also simplify things a pinch, because you'd only have to send the character, instead of both the code and printable letter.

The only downside I could think of would be if somewhere there existed a keyboard with actual physical buttons for the characters we've chosen.  But I doubt such a keyboard exists.  

Any thoughts?

[John Asmuth]

On Tue, May 1, 2012 at 8:58 AM, Michael Schneider <michael.a...@gmail.com> wrote:

I wouldn't mind working on that.  However, it sounds like we have some design decisions to make first.

I agree, and now is the time to talk about them.

 

 One idea I had is, since Go does everything utf8 by default, attempt to take advantage of that.  Instead of inventing yet another set of codes, could we do something like pass a utf8 arrow character for cursor keys (→, ←, ↑, or ↓).  I'm sure we could agree on appropriate symbols for shift, alt, control, and super as well.  This would also simplify things a pinch, because you'd only have to send the character, instead of both the code and printable letter.

The only downside I could think of would be if somewhere there existed a keyboard with actual physical buttons for the characters we've chosen.  But I doubt such a keyboard exists.  

 

Schemes like this are tempting, and they make for extremely readable code. One strong downside that you didn't mention is it can be very difficult to *write* code that uses a lot of unicode glyphs. I ran into this issue with a statistics library I wrote a while back. There are εs and αs all over the place, making it very familiar for people who do a lot of statistics, but it is very difficult to type those letters unless you take some time to set up your keyboard.

I would much rather send "left" than "←". This is what xgb already does ("Left_arrow" actually).

Perhaps something like

type KeyEvent struct {
  Glyph string
}
type KeyDownEvent struct {
  KeyEvent

  Letter string 

  Chord string
}

The Glyph refers to the actual key-press that triggered this event. So it could be "a", "backspace", "delete", "up arrow" etc.

The Letter refers to an actual typed thing to go on the screen, and "" if nothing. So, "a", "A", "!", but not "backspace" etc. Something to be inserted directly into the viewable text.

And the Chord refers to the set of keys being held down, separated by a "-" and in some sorted order. So, typing "A" would cause these two events:

{ Glyph: "shift", Letter: "", Chord: "shift"}, { Glyph: "a", Letter: "A", Chord: "shift-a"}

What do you think?

[Michael Schneider]

Schemes like this are tempting, and they make for extremely readable code. One strong downside that you didn't mention is it can be very difficult to *write* code that uses a lot of unicode glyphs. I ran into this issue with a statistics library I wrote a while back. There are εs and αs all over the place, making it very familiar for people who do a lot of statistics, but it is very difficult to type those letters unless you take some time to set up your keyboard.

I would much rather send "left" than "←". This is what xgb already does ("Left_arrow" actually).

Perhaps something like

type KeyEvent struct {
  Glyph string
}
type KeyDownEvent struct {
  KeyEvent

  Letter string 

  Chord string
}

The Glyph refers to the actual key-press that triggered this event. So it could be "a", "backspace", "delete", "up arrow" etc.

The Letter refers to an actual typed thing to go on the screen, and "" if nothing. So, "a", "A", "!", but not "backspace" etc. Something to be inserted directly into the viewable text.

And the Chord refers to the set of keys being held down, separated by a "-" and in some sorted order. So, typing "A" would cause these two events:

{ Glyph: "shift", Letter: "", Chord: "shift"}, { Glyph: "a", Letter: "A", Chord: "shift-a"}

What do you think?

I like it.  I especially like the separate Glyph and Letter variables.  They provide clarity without re-introducing the random arbitrary numbering scheme.  Out of curiosity, why did you move Glyph into a separate struct?  Is it because KeyEvent will be carrying all values common to both KeyDownEvent and KeyUpEvent?

And also (I'm not trying to be antagonistic, but I like to be thorough when it comes to design decisions), would it make more sense to have Chord be []string?  Since it's holding multiple values?  Checking for a chord (which would become a common paradigm in event programming) would look like "len(Chord) > 0" rather than the more verbose "len(strings.Split(Chord, "-")) > 0".

[John Asmuth]

On Tuesday, May 1, 2012 10:35:21 AM UTC-4, Michael Schneider wrote:

I like it.  I especially like the separate Glyph and Letter variables.  They provide clarity without re-introducing the random arbitrary numbering scheme.  Out of curiosity, why did you move Glyph into a separate struct?  Is it because KeyEvent will be carrying all values common to both KeyDownEvent and KeyUpEvent?

That was the intention, yes. Also, I think KeyTypedEvent would get the Letter and Chord fields, with KeyDownEvent and KeyUpEvent just having the glyph.

 

And also (I'm not trying to be antagonistic, but I like to be thorough when it comes to design decisions),

Don't apologize - this is the place for it.

 

would it make more sense to have Chord be []string?  Since it's holding multiple values?  Checking for a chord (which would become a common paradigm in event programming) would look like "len(Chord) > 0" rather than the more verbose "len(strings.Split(Chord, "-")) > 0".

The thing with having it be a single string is that it makes comparison very easy. You can do ke.Chord == "ctrl-alt-delete", and since you know the glyphs will be in sorted order you know that you don't have to check for "alt-ctrl-delete" too. I also thinking that checking for the existence of *any* chord, ie "len(strings.Split(Chord, "-")) > 0", will be very rare, while checking for the existence of a particular chord will be very common. String comparisons can also be done efficiently in a type switch, while slice comparisons cannot.

[Michael Schneider]

The thing with having it be a single string is that it makes comparison very easy. You can do ke.Chord == "ctrl-alt-delete", and since you know the glyphs will be in sorted order you know that you don't have to check for "alt-ctrl-delete" too. I also thinking that checking for the existence of *any* chord, ie "len(strings.Split(Chord, "-")) > 0", will be very rare, while checking for the existence of a particular chord will be very common. String comparisons can also be done efficiently in a type switch, while slice comparisons cannot.

Okay, I can live with that, as long as we ALWAYS put them in the same canonical order every time.  I'm having gut-wrenching flashbacks to Qt events where I would constantly check for both "SHIFT+CTRL+D" and "CTRL+SHIFT+D".  And don't even get me started about when there were three modifiers...

[John Asmuth]

On Tuesday, May 1, 2012 12:05:43 PM UTC-4, Michael Schneider wrote:

Okay, I can live with that, as long as we ALWAYS put them in the same canonical order every time.  I'm having gut-wrenching flashbacks to Qt events where I would constantly check for both "SHIFT+CTRL+D" and "CTRL+SHIFT+D".  And don't even get me started about when there were three modifiers...

Right, I suppose the motivation for that is that it remembers the order in which the keys were pressed, but if you want to be that specific about it you can just track it yourself by watching glyphs.

For the ordering, I guess a first idea is to list all modifier keys first, in alphabetical order, and then list all typings keys, also in alphabetical order. Typing keys include backspace, delete, return, since they modify a normal text input when typed by themselves. Things like control, shift etc, don't do anything if you type them by themselves, so they are modifiers.

So we'd get

alt-ctrl-delete

ctrl-shift-a

etc

It actually doesn't really matter what we do specifically, as long as it's exactly the same each time. Most people will print out the key chord for the combo they want and copy that string into their code.

- John

[Michael Schneider]

For the ordering, I guess a first idea is to list all modifier keys first, in alphabetical order, and then list all typings keys, also in alphabetical order. Typing keys include backspace, delete, return, since they modify a normal text input when typed by themselves. Things like control, shift etc, don't do anything if you type them by themselves, so they are modifiers.

I like this convention.  Modifier keys and then typing keys.  And just alphabetizing them is simple enough convention.  I was thinking something similar myself.

 

It actually doesn't really matter what we do specifically, as long as it's exactly the same each time. Most people will print out the key chord for the combo they want and copy that string into their code.

Agreed.  Heck, that's what I'd do.  :) 

[Michael Schneider]

In a Chord, how do we want to refer to the key that is referred to as "Windows Key" on Windows, "Super" on Mac, and I think it's called "Meta" on Linux?  I'm up for anything but "Windows Key".  It sounds too proprietary.

[John Asmuth]

'super'.

[John Asmuth]

What platform are you working from, btw? When you have something I'd like to take a look at it and map out the other two platforms.

I think the unifying bit would be best as a function that maps what comes in as code and letter to the struct { Glyph string; Letter string} type. The stuff to map that into chords... perhaps that code would go in go.uik rather than go.wde? In any case it'd be separate.

[Michael Schneider]

What platform are you working from, btw? When you have something I'd like to take a look at it and map out the other two platforms.

I've been working on Mac.  I have a feeling that I'll be sticking a lot to the Mac.  I love linux, but I use Mac at work, and being so accessible, I've been picking away at go.wde on little breaks here and there.  I've committed what I have so far to my github account (github.com/KarateCode/go.wde).  I've got everything working except the 'super' key.  The events don't seem to be firing up from the cocoa end of things.  If you want to take a look at what I've done, just run "go run cocoa/wdecocoa/main_darwin.go".  You may have to recompile and install the gomacdraw xcode portion as well.  I had to make a quick tweak to it.

 

If you want, I can send you a pull request in Github, but I'll try to get that super key working in the mean time.

 

I think the unifying bit would be best as a function that maps what comes in as code and letter to the struct { Glyph string; Letter string} type. The stuff to map that into chords... perhaps that code would go in go.uik rather than go.wde? In any case it'd be separate.

I get what you're saying.  For now, everything is sitting in the cocoa section.  But when all three platforms are there, we can definitely refactor that mapping code so that it's common to all of them.

I'm not sure yet if that mapping code should go in go.uik.  I like the idea of all system dependent codes going in go.wde, leaving only the Glyphs, Letters, and Chords for go.uik.  

[John Asmuth]

On Thu, May 3, 2012 at 9:45 AM, Michael Schneider <michael.a...@gmail.com> wrote:

You may have to recompile and install the gomacdraw xcode portion as well.  I had to make a quick tweak to it.

What change did you need to make?

 

If you want, I can send you a pull request in Github, but I'll try to get that super key working in the mean time.

Let's wait until it's settled, first.

btw make sure to add yourself to go.wde/AUTHORS before you pull-request.

 

I'm not sure yet if that mapping code should go in go.uik.  I like the idea of all system dependent codes going in go.wde, leaving only the Glyphs, Letters, and Chords for go.uik.  

 

I'm thinking a new event type KeyChord struct { Chord string }. A key stroke that is part of a chord should not be interpreted as a typed letter, so wde shouldn't let it be a possibility.

[Michael Schneider]

What change did you need to make?

I added "e.data[2] = [theEvent modifierFlags];".  modifierFlags is a bitwise variable that holds any and all the modifier keys that are down.

 

btw make sure to add yourself to go.wde/AUTHORS before you pull-request.

Thanks for the honor.  :) 

I'm thinking a new event type KeyChord struct { Chord string }. A key stroke that is part of a chord should not be interpreted as a typed letter, so wde shouldn't let it be a possibility.

You might have to clarify what you're getting at for me.   As far as I can tell that's what I'm already doing; a modifier key is never passed as a Letter.   It only sends when there is a full chord with a valid character on the end.  I don't have KeyDown or KeyUp events working yet, only the KeyTypedEvent.  That isn't behavior I programmed on purpose, there seems some funny behavior with the events coming in.  Cocoa seems to be passing back to the Go layer way less events than I expect.  There are no events involving 'super', and there are no keyUp events.  The kicker is, when I run gmdTest from XCode, I get both those events firing.  Maybe there's some funny business in the cgo layer...?  I'll keep tinkering away and see what I can turn up.

And btw, if you've got the itch to program, you have my blessing to dive into the linux side of keyboard events.  :)

[Michael Schneider]

My bad, keyup events firing.  

[Michael Schneider]

Update: 

I've finished KeyDown, KeyUp, and KeyTyped events with KeyTyped events only firing when it's a fully qualified chord.

Still having the 'super' problem.  I keep tinkering, but I'm really not making any headway on it...

[John Asmuth]

I wouldn't be suprised if apple simply didn't report this key. Absolutely all menu chords use the command key, and it is used for nothing else as far as I'm aware.

However, I know that you can use it in a few games, so I bet if we figure out a way to inspect the set of pressed keys, we will see evidence of command being pressed. This doesn't help much, though, since we will not be running a key-polling busy-wait in the background.

There is certainly *some* way to get it, though, since if you run the xgb version of the test then command is reported as "Meta_L" or "Meta_R".

I'm ok leaving it as future work.

Incidentally, leave the left/right identifiers off of the chord construction, but they should go into the Glyph field.

Do you think you could create a set of constants in a new file go.wde/keys.go that looks like

type Glyph string

const (

  KeySuper Glyph = "super"

  KeyLeftAlt Glyph = "left_alt"

  KeyLeftArrow Glyph = "left_arrow"

  KeyA Glyph = "a"

  KeyPercent Glyph = "%"

)

etc? Don't need to complete it, just start it. But we should have a single place that collects the glyph identifiers, and when it's not obvious say what keys they correspond to on each system.

- 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/-/M5lzCGNACMwJ.

[Michael Schneider]

I wouldn't be suprised if apple simply didn't report this key. Absolutely all menu chords use the command key, and it is used for nothing else as far as I'm aware.

 

It fires if you run the gmdTest demo you wrote (if you simply add some NSLog'ing, it becomes very apparent), and that's what has me so mystified.  It only doesn't fire when running it from cocoa/wdecocoa/main_darwin.go

Do you think you could create a set of constants in a new file go.wde/keys.go that looks like

type Glyph string

const (

  KeySuper Glyph = "super"

  KeyLeftAlt Glyph = "left_alt"

  KeyLeftArrow Glyph = "left_arrow"

  KeyA Glyph = "a"

  KeyPercent Glyph = "%"

)

etc? 

Consider it done.  :) 

[Michael Schneider]

I just finished the new key mapping.

[John Asmuth]

So why does it not recognize the super key? In the old version when you hit command on mac, it reports key code 54 or 55, depending on which one...

[Michael Schneider]

So why does it not recognize the super key? In the old version when you hit command on mac, it reports key code 54 or 55, depending on which one...

Just to clarify, I'm actually getting keydown and keyup events on the super key.  But any key combinations involving super don't work.  To break it down, if I am attempting a "super+a" chord, the keydown event for super will fire, but not when I press the "a".