Shiny

[Joe Blue]

Shiny looks OK for building desktop apps.

A tone built anything useful with it ?

[Dave MacFarlane]

The easiest (but somewhat unreliable) way I can think of to get an
idea of who's using it is to look at the importers on GoDoc:

https://godoc.org/golang.org/x/exp/shiny/screen?importers

I don't know what you consider "useful", but the small-ish list of
non-internal importers seems to suggest that there's not many people
using it so far, but it's also still under x/exp, so that's not
entirely surprising.

- Dave

On Tue, Aug 16, 2016 at 7:35 AM, Joe Blue <joeb...@gmail.com> wrote:
> Shiny looks OK for building desktop apps.
>
> A tone built anything useful with it ?
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[howar...@gmail.com]

I've been working with it lately. I got fairly far in writing a drop-in visualizer for my algorithms, but I ran into a snag when I went to add dynamically generated editing for parameter values. The widget.NewText(), in spite of being used in an Example called TextEdit, does not appear to actually have any GUI support for editing yet.

It is also slightly unclear what version of the language it is built for. I think they have been advancing with Go, and have not made efforts towards backwards compatibility, and I had to make several hand-edits after updating, to get it to compile under Go 1.5.

So, from my examination, the event handling/mainloop is fine (at least on Linux using X11 driver), painting is fine, widget layout is acceptable-ish, but widget depth is exceedingly poor. Basically has image rendering widgets, labels, and text widgets with automatic text layout, and that is it.

No buttons (though they aren't hard to implement from a label), no radio boxes, no built-in scrollbars that I could find, no actual text editors, no lookups/drop-downs/choosers, no listboxes. And certainly nothing akin to a grid/spreadsheet control with embeddable widgets.

So, right now, as Dave MacFarlane's suggestion also shows, it is viable for creating renderers/viewers.

Howard

[Dave MacFarlane]

On Tue, Aug 16, 2016 at 12:56 PM, <howar...@gmail.com> wrote:
> No buttons (though they aren't hard to implement from a label), no radio
> boxes, no built-in scrollbars that I could find, no actual text editors, no
> lookups/drop-downs/choosers, no listboxes. And certainly nothing akin to a
> grid/spreadsheet control with embeddable widgets.
>

What do you mean "no actual text editors"? By my count of the
importers that GoDoc knows about 3 out of 8 of the projects that are
using it are text editor apps.

- Dave

[howar...@gmail.com]

On Tuesday, August 16, 2016 at 12:19:13 PM UTC-5, Dave MacFarlane wrote:

What do you mean "no actual text editors"? By my count of the
importers that GoDoc knows about 3 out of 8 of the projects that are
using it are text editor apps.

- Dave

Go to exp/shiny/examples/textedit. 

go run main.go

Try to edit. Nothing happens. Click - no caret appears. Type, nothing happens. Try to select text, nothing happens. 

Look at the list of GoDoc projects:

go-vu: not clear what this is, but it looks like a GUI implementation of its own, resting on top of Cocoa, mobile, or Shiny, but https://github.com/achille-roussel/go-vu/blob/master/text.go looks like his custom implementation of a text edit.

view-fits: image viewer for specific file type.

de: programmer's text editor - uses the Shiny screen as an image window, renders text and line numbers into that on its own, does not use any Shiny widgets (hardly surprising - this is a VI style mode-based editor, so a traditional text edit would hardly be a viable basis). See https://github.com/driusan/de/blob/master/kbmap/insertmode.go for basic implementation of text editing

T: T text editor. https://github.com/eaburns/T/blob/master/ui/textbox.go - this is his own textbox implementation - presumably because Shiny does not have a usable one yet.

hplot: histogram and function plotter.

linedrawer: draws steps from 1-dimensional cellular automata

goapple2: apple II emulator, using Shiny as a framebuffer/eventloop, basically. Again, not using built-in text widgets, doing its own rendering and text handling.

graphics/cmd/edit: popping up a couple of levels, to graphics, here is a line from their readme: "editor provides a graphical, editable text area widget." Again, their own implementation of a text editor widget.

So, again, not one of these programs uses the Shiny text widget. "sigint.ca/graphics/editor" looks like an interesting implementation that I may try to use, as it appears on the face of it to have been designed as a drop-in usable widget with minimal dependency contamination.

But my basic point stands - the exp/shiny implementation lacks the basic widgets to implement the average desktop application, particularly of the data entry variety, but is suitable as a backing framebuffer/eventloop. Expanding your dependencies may gain you a text editor widget, but you would still be on your own for implementing buttons, radio-buttons, drop-down/lookup/choosers, list selectors, tree controls, grid controls. Unless it is your *goal* in the first place to write such a set of widgets, then currently you are probably better off implementing back-end logic in Go and front-end interfaces in something else, or looking into alternative more feature-complete GUI packages for Go.

The text widget itself was only added to Shiny on June 12, and there is still a comment in the file that reads "// TODO: cursors + editing (not just viewing) text, key + mouse events, // scrolling, load/save, clipboard." so I don't think I am making any claims the developers would not acquiesce to. Surely this will change over time, and the implementations above are evidence enough that Shiny is a viable platform on which to build complex widgets. I am not at all meaning to disparage the project, just trying to offer a bit of my own experience.

Howard

[Joe Blue]

Thanks. I looked there before.

It's a shame that only the shiny author is the only one on this from Google to improve it.

There are bits and pieces es floating around and even a roadmap in github to build material design widgets.

Dart / flutter / mojo is getting much more resources, with vanadium and syncbase. It's very easy too.
I am hoping the glfw drivers for flutter get some love for desktop in the flutter repo.

Or help on the shiny widgets, and stick with golang for GUI.

Anyone else care to give an opinion ?

[Seb Binet]

On Wed, Aug 17, 2016 at 2:38 PM, Joe Blue <joeb...@gmail.com> wrote:

Thanks. I looked there before.

It's a shame that only the shiny author is the only one on this from Google to improve it.

There are bits and pieces es floating around and even a roadmap in github to build material design widgets.

Dart / flutter / mojo is getting much more resources, with vanadium and syncbase. It's very easy too.
I am hoping the glfw drivers for flutter get some love for desktop in the flutter repo.

Or help on the shiny widgets, and stick with golang for GUI.

Anyone else care to give an opinion ?

I have used a bit x/exp/shiny (in view-fits and hplot)

the API is indeed not yet stable (hence the EXPerimental in x/exp)

but Nigel and David are working on this package (the internals, the various drivers, the exported API, the performances).

at times it is a bit frustrating but at the end of the day, for my usage, it fit the bill quite well.

that said, I think it is quite clear that shiny is not yet ready for prime time, for all the use cases of a complete GUI toolkit.

I hope it will come to that, but it isn't the case yet.

for the time being, I would recommand net/http + (polymer|bootstrap|whatever)

net/http served me well (ha!)

-s

[Joe Blue]

Thanks I am using polymer and bootstrap and electron too. But I hate it, and so why I turned to flutter.

I might check out your code. I think the basic MDL web GUI stuff could easily be make to work with shiny, if we don't want any glowing animation stuff, etc. Just like how MDL is is nice simple implementation of material design.

The only other thing is a markdown editor and viewer.

Responsive reflow ? Do it by hand for now will do.

[Nigel Tao]

On Wed, Aug 17, 2016 at 2:56 AM, <howar...@gmail.com> wrote:
> It is also slightly unclear what version of the language it is built for. I
> think they have been advancing with Go, and have not made efforts towards
> backwards compatibility, and I had to make several hand-edits after
> updating, to get it to compile under Go 1.5.

Huh, that's news to me. Last I looked, it ran out of the box on Go
1.5. What hand-edits did you make?

[Nigel Tao]

On Wed, Aug 17, 2016 at 11:11 PM, Seb Binet <seb....@gmail.com> wrote:
> that said, I think it is quite clear that shiny is not yet ready for prime
> time, for all the use cases of a complete GUI toolkit.
> I hope it will come to that, but it isn't the case yet.

Yes, it's not yet ready for prime time. We're working on it...

[Joe Blue]

Do you want anyone to help on the material design "widgets" yet ?

[Joe Blue]

Howard,

Your summary is excellent. I went through all the same repo's and came to the same conclusions. Thanks for summarising the state if play.

There is also some very impressive work by Skinner over at:
https://github.com/dskinner/material

The branch called mediansdf has impressive font improvements.

The whole project is doing more than just fonts.

I was wondering if anyone is interested in making a repo that is a kitchen sink demo of the current state of play with me ?
I know we don't have much yet. But it will act as a catalyst for others to see where the holes are and try to fill them in with different attempts.
I know the shiny repo has some examples, it's also a pain for most golang developers because it does not use standard github PR mechanisms.

[howar...@gmail.com]

Thanks Joe. I've got some samples already for testing what I'm working on... but right now, I'm hitting a wall. The Shiny docs say that OnInputEvent on widgets gets called on keyboard events:

// OnInputEvent handles a key, mouse, touch or gesture event.

but in my testing trying to integrate "sigint.ca/graphics/editor" as a temporary replacement for the nonfunction Text widget, a simple log.Printf("Handling event (%v)\n", e) on a widget reports mouse movement, clicks, mousewheel, but no keyboard events at all (aside from the key.Modifiers() state on mouse events - i.e. whether Ctrl is held while dragging). Which makes passing those events through to the sigint control impossible. 

If I had to guess, it looks to me like this is due to lines 117, 118 in widget.go:

case gesture.Event, mouse.Event:

root.OnInputEvent(e, image.Point{})

When I change it to 

case gesture.Event, mouse.Event, key.Event:

then I can make the sigint.ca text editor work in the widget tree, but obviously, requiring hand-editing of dependencies is not a viable path, nor is vendoring in a customized shiny. Well, the vendored one would work for me... but I'm trying to build something that people would willingly drop in as a lightweight means of getting a quick dev gui, and including a frozen snapshot of a rapidly cycling experimental dependency doesn't seem like a good way to do that. Hopefully I can get the change into upstream and not worry about it.

On a different note, I will throw in that if you try anything with the Widgets and get no visual output, and testing shows your paint functions are never called, you probably have not included a widget.NewSheet() call wrapping your widgets. You can have more than one of these (to represent regions that will be independently scrollable, when scrolling is implemented), but most of the built-in widgets assume you have at least one. 

[howar...@gmail.com]

My poor brain is melting. I was just worried about vendoring shiny and the effect of that on producing something to be easily embedded in other people's programs... while writing a (successful, mind!) wrapper of sigint.ca/graphics/editor that makes it fit the Widget node.LeafEmbed model of shiny... 

And when I tried to pass in mouse events as well as the keyboard events I was already passing, I got this error:

./textedit.go:65: cannot use e (type "golang.org/x/mobile/event/mouse".Event) as type "sigint.ca/graphics/vendor/golang.org/x/mobile/event/mouse".Event in argument to t.editor.SendMouseEvent

Sooo.... the library I am adding to extend the missing functionality in shiny, already vendors shiny and mobile. o_O

Though, only mobile/event/mouse/mouse.go, which based on its alterations, I assume fits with modifications to their vendored shiny, as otherwise I can't see how it could be filled out. But which means that when embedding in un-vendored shiny, you can't send them any mouse events... as far as I can see, you can't even manually repackage events in the format they want, because you can't import the vendored package from another package.

I also can't just vendor sigint.ca and add a WrapMouseEvent(e unvendoredevent) type call, since the new 1.7 vendoring stuff does automatic rewriting, so I can't get at *both* the vendored *and* the unvendored on either side. I could possibly pass it through as an interface{} and unpack it with reflection (bleh!), or create yet a third mouse.Event that is actually on a different path, so is accessible to both, and convert it twice (ick, but less so). Not really sure where to go with this, but I guess mouse interaction is not critical to my primary intended use... so back to what I was trying to accomplish.

[Nigel Tao]

On Thu, Aug 18, 2016 at 6:12 PM, Joe Blue <joeb...@gmail.com> wrote:
> Do you want anyone to help on the material design "widgets" yet ?

It's great that there's community interest in Shiny, but as I said,
it's not ready yet. I'll let y'all know when enough has been built and
settled that more contributors will be helpful.

[Nigel Tao]

On Fri, Aug 19, 2016 at 9:24 AM, <howar...@gmail.com> wrote:
> Thanks Joe. I've got some samples already for testing what I'm working on...
> but right now, I'm hitting a wall. The Shiny docs say that OnInputEvent on
> widgets gets called on keyboard events:
>
>
> // OnInputEvent handles a key, mouse, touch or gesture event.
>
> but in my testing trying to integrate "sigint.ca/graphics/editor" as a
> temporary replacement for the nonfunction Text widget, a simple
> log.Printf("Handling event (%v)\n", e) on a widget reports mouse movement,
> clicks, mousewheel, but no keyboard events at all

Yes, this is TODO, and needs a design for how keyboard focus will work.

As I said, Shiny is not ready yet for general use. Please be patient.

[Sam Boyer]

Yep, this is one of those nasty, known issues with vendoring right now. this exact issue was first raised on this list here: https://groups.google.com/d/msg/golang-nuts/AnMr9NL6dtc/UnyUUKcMCAAJ. 

We've got a crew coming together soon to address this issue, among many others: https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8/edit#

[Joe Blue]

fair enough :)

[Daniel Skinner]

There is also some very impressive work by Skinner over at:
https://github.com/dskinner/material

The branch called mediansdf has impressive font improvements.

Thanks for the shout out, though I'm already looking at dropping that branch.

I'm interested in shiny as well but waiting for things to move along a bit further.

[Joe Blue]

Danial,

Piano is really impressive. The Material touch effects are very snappy too !! 

Boxes too. 

With both Piano and Boxes running Android they are still snappy in GenyMotion and on real Android device.

Its allot of fun playing around with different aspects of the code.

Thanks for the update about the "mediansdf" branch not going forward. The third party code and paper looked impressive in terms of what it promised for Font rendering quality. 

---

Regarding Text editors. I have been playing with a few different implementations.

This one has worked out the best for me. 

https://sigint.ca/graphics/

https://godoc.org/sigint.ca/graphics

Its has: scrolling, edit, save key and mouse integration.

The dependencies with shiny are vendored in the repo, so you should be able to try easily.

I am trying to bring it up the the latest shiny version.

At the moment I am fixing the mouse code that is dependent on shiny. 

../../editor/mouse.go:14: undefined: mouse.ButtonScroll

../../editor/mouse.go:44: e.PreciseScrolling undefined (type mouse.Event has no field or method PreciseScrolling)

../../editor/mouse.go:45: e.ScrollDelta undefined (type mouse.Event has no field or method ScrollDelta)

../../editor/mouse.go:46: e.ScrollDelta undefined (type mouse.Event has no field or method ScrollDelta)

../../editor/mouse.go:49: e.ScrollDelta undefined (type mouse.Event has no field or method ScrollDelta)

../../editor/mouse.go:63: e.Pos undefined (type mouse.Event has no field or method Pos)

../../editor/mouse.go:68: e.Pos undefined (type mouse.Event has no field or method Pos)

../../editor/mouse.go:82: e.Pos undefined (type mouse.Event has no field or method Pos)

[Daniel Skinner]

Its definitely interesting but I was pursuing a technique to work with rasterized images instead of bezier curves or vector data, the results just weren't consistent enough to my taste. If I were to use it, It'd likely be more productive for use to link in the current work via cgo since the research is still on-going: https://github.com/Chlumsky/msdfgen

But for now I'm simply addressing the more generic issue of binpacking images (including glyphs) for rendering while removing the need for the material/text package so multiple fonts can be employed live along with image assets.

[Joe Blue]

Hey

All gophers that want a GUI toolkit...
We are doing a bring up that is planned to work on all desktops, mobile and embedded.

Support the following app types::
forms, 2d surface and 3d surface.

Will have:
Material design components, virtual keyboard, cut and paste, audio and video capture and playback.
Intimate gesture control and keyboard mapping.
Printing via pdf

We are right now working out if we use OpenGL or Vulkan.
Also the best immutable data binding approach.

Then the long work on building pixel perfect material design conformance with CI testing of it.

If you interested in forging the approach or have ideas please ping me. The system is not ready for general usage yet so it's better if people that have some golang open GL experience ping me so we can make sure the design covers / considers your needs.

Joeblew99 at Gmail dot com.

[Elias Naur]

Hi,

I had plans to work on a GUI library that follows many of the design choices from Flutter. In particular, I'd like to experiment with immediate mode drawing and a layout manager based on Cassowary. As backend I plan to avoid too much upfront work and bind to Skia. I'd be very interested in your approach as well.

 - elias

[Ged Wed]

have a look here:

https://docs.google.com/document/d/1mXev7TyEnvM4t33lnqoji-x7EqGByzh4RpE4OqEZck4/edit#

[sqweek E.]

There's also go.wde: https://github.com/skelterjohn/go.wde

Although the widget situation is no better there (intentionally; it's reason to exist is to provide a platform independent interface to windows/framebuffers/events). Wde doesn't do mobile at all, but has pretty decent support for win32/OSX/X11 features (eg. zoom/scroll touchpad gestures, mouse cursors).

Probably the most interesting part of its design is that it allows your event loop and rendering loop to run in separate goroutines, which is a nice decoupling.

-sqweek