gomobile: what's the right way to make widgets?

[Fino]

hello all,

I was playing around with gomobile this weekend, successfully run the examples on my rooted Intel x86 phone.

it seems most of the API will call opengl es2 functions to draw various images on a screen.

then how to make a common 2D widgets?  like textbox, button, imagebox, listview...

I have no knowledge on GUI lib architecture,  nor 3D/2D game's architecture, 

what's the plan for gomobile team? 

will these widgets will implement natively in GO,  sit on GL ES (GPU enabled),  as a layer in GL ES context, 

or should a APP use Java/Obj-c 's widgets at top level, just use GO's libs as native .so libs embedded in the APP? 

BR-fino 

[Tyler Compton]

As far as I understand it, the standard Android widget toolkit will never be accessible in a purely Go app. It would be an enormous undertaking to re-implement that much code in Go. If you want Android widgets, you're going to have to use Java for the frontend and call the Go code from there.

Somebody could implement a new widget toolkit to work with Gomobile. Maybe something like http://godoc.org/golang.org/x/exp/shiny?

[Andrew Williams]

I'd be very interested to see if it would be possible to implement an x/mobile backend for Fyne (github.com/fyne-io/fyne).

The widgets are designed to work across various platforms and the EFL backend is just one possible implementation.

Could be interesting if we can use the same app code to work on desktop and mobile?

Is anyone working in this space who could offer some advice?

Thanks,

Andrew

[Space A.]

I wish go2 team would focus on cross-platform GUI rather than nobody-needed generics after all. There is nothing you can do atm, write your own library I guess...

пятница, 26 октября 2018 г., 19:48:37 UTC+3 пользователь Andrew Williams написал:

[Gerald Henriksen]

On Sat, 27 Oct 2018 07:02:46 -0700 (PDT), you wrote:

>I wish go2 team would focus on cross-platform GUI rather than nobody-needed
>generics after all. There is nothing you can do atm, write your own library
>I guess...

An acceptable cross-platform GUI is a major undertaking to create an
even half way acceptable outcome.

Far better to somehow interface with an existing solution like Qt
which has already spent the decades creating something that mostly
works.

[Robert Engels]

I’m away from computer right now but the latest one that was posted about here seems very well done and looks decent as well.

Sent from my iPhone

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

[Nathan Verrilli]

Regarding cross-platform GUI:

The below author has it precisely correct. As, after decades of effort, Qt 'mostly works' suggests strongly that those who care  about their UI will end up implementing UI natively, and separating it from their code. Those who don't care will be happy to use something that 'mostly works'.

Neither case suggests that a cross-platform GUI is a useful addition to Go (and my own conclusion is that they show such a platform is not).

Cheers,
Nathan

[Ian Lance Taylor]

On Sat, Oct 27, 2018 at 7:02 AM, Space A. <reexi...@gmail.com> wrote:
>
> I wish go2 team would focus on cross-platform GUI rather than nobody-needed
> generics after all. There is nothing you can do atm, write your own library
> I guess...

Realistically a good cross-platform GUI is far beyond the capabilities
of the current Go team.

Generics are not.

It would be nice if cross-platform GUIs were easier to write, but they
are not. The incentives are all wrong. Platform vendors want to make
their platform look nicer and work better, and that inevitably means
that it is harder to write a single application that looks good on
every platform. The only people who benefit from cross-platform GUIs
are developers producing applications for multiple platforms. All
else being equal, the platform vendors would prefer that they write
applications that only work on their platform. And any platform
vendor with sufficient market share has the power to make decisions
that move in that direction rather than toward better cross-platform
GUI support.

Ian

[robert engels]

This is the cross  I was referring to https://github.com/fyne-io/fyne

[Scott Cotton]

Very wise observation.  

I don't like seeing 3rd party (usually C) code doing what could be done in Go, perhaps one way to move forward

would be for the community to consider writing native single-platform gui APIs without 3rd party code dependencies.  

Then a cross platform App would just implement for each platform.  That would be more work for app writers but provide more support for optimal UIs, but then you'd know that on this platform, these accounts are here and passwords are managed by XYZ and .... I think many apps do this in  C/C++, and/or a mix of languages (C#, swift, js, ...).    

Fyne looks nice, as Robert Engels pointed out, but it has a dependency on some parts in C and it's not clear (upon perusal) how to 

access platform specific stuff.  Good place to roll out something cross platform.

Ian

[Lucio]

On Sunday, 28 October 2018 01:58:56 UTC+2, Scott Cotton wrote:

[ ... ]

Then a cross platform App would just implement for each platform.  That would be more work for app writers but provide more support for optimal UIs, but then you'd know that on this platform, these accounts are here and passwords are managed by XYZ and .... I think many apps do this in  C/C++, and/or a mix of languages (C#, swift, js, ...).    

That way lies Window Registry (madness?). Does the real answer lie in that? It has not yet been found to be so.

 

Fyne looks nice, as Robert Engels pointed out, but it has a dependency on some parts in C and it's not clear (upon perusal) how to 

access platform specific stuff.  Good place to roll out something cross platform.

My clearly uneducated thoughts go to exp/shiny (disclosure: the Plan 9 ancestry appeals to me) and HTML-5 which I know nothing about. Are there other alternatives?

Lucio.

[Scott Cotton]

On Sunday, 28 October 2018 05:13:15 UTC+1, Lucio wrote:

On Sunday, 28 October 2018 01:58:56 UTC+2, Scott Cotton wrote:

[ ... ]

Then a cross platform App would just implement for each platform.  That would be more work for app writers but provide more support for optimal UIs, but then you'd know that on this platform, these accounts are here and passwords are managed by XYZ and .... I think many apps do this in  C/C++, and/or a mix of languages (C#, swift, js, ...).    

That way lies Window Registry (madness?). Does the real answer lie in that? It has not yet been found to be so.

Yes, all this is just opinions.  cross-platform GUIs suffer from the wrong incentives Ian pointed out.  Also, in these days, GUIs are more and more integrated with platform specific organisation of services such as security, accessibility, ...  I'm not a windows user so I can't say much about Registry.

  

 

Fyne looks nice, as Robert Engels pointed out, but it has a dependency on some parts in C and it's not clear (upon perusal) how to 

access platform specific stuff.  Good place to roll out something cross platform.

My clearly uneducated thoughts go to exp/shiny (disclosure: the Plan 9 ancestry appeals to me) and HTML-5 which I know nothing about. Are there other alternatives?

I like exp/shiny too.  Robert pointed out fyne.io which looks good.  none of these will look 100% native.  All will suffer from the fact that platform vendors have their own APIs for guis and they want people to use those APIs, so they make it hard for cross-platform guis to compete.

Scott

 

Lucio.

[Laurent Moussault]

I think less and less people care about native UIs. This was not the case a few years ago, but nowadays web-like interfaces, even for desktop applications, is becoming the new standard. Most "non-tech" people interact with their computers mostly through the web browser, so a similar interface is what will be the most intuitive for them. I wouldn't be surprised if native UIs are actually looking "scary" to them, because this is the interface that is used to do all the technical things they don't really care for (like configuration and other administration tasks).

Unfortunately, this means that, currently, more and more developers turn towards web technologies to develop desktop applications (e.g. electron, react native, or a few other proprietary offers). The end result being that each application integrates layers upon layers of mostly inadequate technologies (web server, node.js...). Some will argue that the main reason behind this trend is that there is a lot of available web developers familiar with the tech, but I think the flexibility in design is a more decisive factor.

IMHO there is vacuum right-now, an opportunity for a native framework that allows the same design freedom as web interfaces, but implemented directly on top of the OSes (and Vulkan, probably). I think something like flutter, but implemented in a more mainstream language (and supporting the desktop), would have a shot at success. A GUI framework that does not come with a complete set of ready-to-use widgets and containers (as in traditional native UIs), but allows to easily design custom ones, with beautiful layouts. This is, obviously, a huge amount of work...

[Andrew Williams]

The current Fyne backend is reliant upon the EFL project for rendering but it is written to allow other backends to be introduced (for desktop or beyond).

You're right there is no API for platform specific stuff - if there is a use-case or a requirement it could probably be accommodated though.

Hoping to get feedback from more developers so we can expand in the most useful areas.

Andrew

[Andrew Williams]

The assumption that Fyne has made is that people care about speed and usability more than specifically native feel.

The "native feel" on Windows is in transition anyway and both Windows and Linux already have multiple widget sets.

Taking inspiration from mobile apps and material design it seemed worthwhile looking into lighter weight user interface design that can ignore the constraints of existing toolkit widgets etc.

Andrew

[Robert Engels]

As someone who lived through the criticisms of Java UI not looking native... I think those days are past, hopefully anyway, for the reasons others have cited. As long as the toolkit supports some “native” features like notifications, browser windows, system tray, etc. it shouldn’t be a big issue any more...

[Elias Naur]

On Monday, October 29, 2018 at 11:48:06 AM UTC+1, Laurent Moussault wrote:

IMHO there is vacuum right-now, an opportunity for a native framework that allows the same design freedom as web interfaces, but implemented directly on top of the OSes (and Vulkan, probably). I think something like flutter, but implemented in a more mainstream language (and supporting the desktop), would have a shot at success. A GUI framework that does not come with a complete set of ready-to-use widgets and containers (as in traditional native UIs), but allows to easily design custom ones, with beautiful layouts. This is, obviously, a huge amount of work...

I'm glad you think that; I happen to be working on such an UI library :) Its core is 100% Go, and it only uses Cgo for the necessary integration with the low level OS primitives, input, window management and GPU access (OpenGL ES for now). My library is also inspired by Flutter: it took a lot of work to get into a usable state, but is now very portable and flexible. My other inspiration is imgui: I hope that getting rid of the implicit  widget hierarchy will result in UI programs that are much easier to maintain and keep bug free.

 - elias

[EricR]

A cross-platform GUI library is perfectly doable and cross-platform applications work fine enough for most use cases. Purebasic, REALbasic (now Xojo), Lazarus/Freepascal, Qt for C++ and Python, WxWidgets, Ultimate++, IUP, Swing, etc., all offer more or less cross-platform functionality. I'm also pretty sure that most cross-platform applications are written in such frameworks/languages and not as libraries with multiple native front-ends.

I've seen the suggestion to make a good, kind of 'standard' cross-platform GUI library on many mailing lists for many languages. The reason why it is rejected so often is probably that developers (rightly) fear the task. Interfacing with native APIs is tedious and boring, whereas getting a GUI on your own right is tricky and complicated (think about e.g. a text editor control with rich text). There is often a lack of manpower.  But there is nothing wrong with the idea itself.

[Erwin Driessens]

i wish the the blender GUI would be made stand-alone, ready to port to Go... so clean and fast!

[Fino]

Flutter comes out, and using Dart...

Gophers should all working hard, to make Go occupy more domain area, besides docker, k8s and blockchain.

I think GUI/Game Engine and BigData/Spark(by scala) are 2 domain Gophers should try to walk in.

BR fino

[Scott Cotton]

On Saturday, 10 November 2018 16:49:40 UTC+1, Fino wrote:

Flutter comes out, and using Dart...

Flutter looks nice

 

Gophers should all working hard, to make Go occupy more domain area, besides docker, k8s and blockchain.

100% agreed.  

 

 

I think GUI/Game Engine and BigData/Spark(by scala) are 2 domain Gophers should try to walk in.

There are some cool robot and hardware projects that bring Go to new domain areas.  As far as data stuff goes,

not all of it is "big".  Probably the best way to bring more Go to more new domains is to have quality open source

implementations of things students use -- scientific stuff.  go-num is quality, but lacks in scope.  It would be nice to 

fund and promote its expansion of scope.  There are other scientific domains like formal analysis of programs which

are traditionally not so numeric but rather symbolic/logical.  There are also a lot more domains which have a blend of

domain specific know-how and core math/science functionality, most sciences I'd say.

Media in general will always have a very wide user base because anyone can experience the results.  I think there

is a broad intuition that concurrency in Go would be nice to use in media.

All these domains need more quality core things in Go, not C (or Fortran).

In terms of cross platform/ portability properties of Go, I find it quite disappointing that Docker seems to be best fit 

deployment.  

Ian's observation that the main thing is the relationship of the language to the OS kernel makes sense up to a point.

But nowadays there is so much hardware/device specific stuff (GPUs, audio cards, touch interaction, ...) that it has

become a necessity for a programming language to have near zero-overhead in interfacing these things.  This can

be enabled when the language is low level (or low level enough) and when there are solid libraries interfacing 

OS services.

Go is already very strong in cloud/server oriented space.  I don't want that to influence the core language away 

from everything else and I do want Go in general to focus on expanding the scope of where it excels.

Scott

[komuW]

Do you plan on making that UI library public(open source or not) at some point?

[Elias Naur]

søn. 11. nov. 2018 14.48 skrev komuW <kom...@gmail.com>:

Do you plan on making that UI library public(open source or not) at some point?

Yes. As soon as I'm happy with the API I'll release it under a very liberal licence, perhaps even unlicenced.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/4JF_G7qYBDg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Beoran]

A small gui library is not that much work. Here is my work in progress: https://gitlab.com/beoran/ebsgo/tree/master/zori
It's sleepycat licensed, and uses Allegro as a backend, but it could be made multi backend as well. I am willing to make it MIT if anyone else would like to join.
Or just use it as inspiration.

KR, B.