FAQ
Some applications do it. e.g. Chrome. But that is more of a window
manager issue not the application. The application rarely has the necessary
knowledge to dock two arbitrary applications. I wouldn't be surprised if
some WM already does it.
I didn't see that if you mean the things between chrome and its
applications (those standalone extensions).
Building such an event system isn't complicated
https://play.golang.org/p/u15m5UHbU-. The complex part is the rest of UI.
No. That is not the thing i want to say. I mean this:
type Timer struct{
   dayLightOrMidnight bool
}

func(this*Person)sleep(){
}
func(this*Person)playGame(){
}

t := new(Timer)
p := new(Person)
// i want connect the two objects
I'm not going to define a callback func in the structure...
In your logic, before you do `button.Press`, you've already known, there
will be `OnClick` event on the struct `Button`; But in my logic, before you
do connection, there's nothing defined...
Just like the interface in golang vs interface in other languages!
On Tuesday, May 10, 2016 at 1:36:36 PM UTC+8, Egon wrote:


On Tuesday, 10 May 2016 03:33:10 UTC+3, Wang Yarco wrote:

Great Doc!
+ one my idea, i've just got it several days ago (but don't know where to
add it into your doc):
It should support something like:
[ app A window 1 ] [ app B window 1 ]
When drag `app A window 1` into to `app B window 1`, `app A window 1`
will automatically become a dock window in `app B window 1` just like other
dock window in `app B window 1`.
I mean such actions could happen between apps! Not just windows in an app!
(It seems no current GUI system have such feature)
Some applications do it. e.g. Chrome. But that is more of a window manager
issue not the application. The application rarely has the necessary
knowledge to dock two arbitrary applications. I wouldn't be surprised if
some WM already does it.

So for example, if i'm doing code in macvim, and the same time open a pdf
for reference, i can combine the two into one big window ( seems like in
one application!)

Anyway, go back to our discussion, actually, my attention is the `event
system`. Not the GUI...
Why i take it so much important? The reason is `event system` is a
different thinking in logic.
You call a function, that is active mode; You trigger a function, that is
passive mode.
Building such an event system isn't complicated
https://play.golang.org/p/u15m5UHbU-. The complex part is the rest of UI.

That is the thing in our real world. Either you live in active mode or
you live in passive mode...
So, if no such `event system`, the language itself is just half done...
(that is my feeling)
On Tuesday, May 10, 2016 at 2:18:00 AM UTC+8, Egon wrote:
On Monday, 9 May 2016 18:19:06 UTC+3, Wang Yarco wrote:

Well, i haven't tried everything. But that is the most elegant solution
as i know.
Here's my preliminary research
<https://docs.google.com/document/d/1QtqrrSG1lbnmk8wPTOVNEjfby3zfymS8vHtM8cxy67I/edit>
on different approaches.

Em...though https://github.com/therecipe/qt
<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ftherecipe%2Fqt&sa=D&sntz=1&usg=AFQjCNEPpv5rg-P4P4c8gPXSEFnMM5FwYQ>
seems good...but i would still choose Qt/c++ when i want to do desk
application.
I think only a pure qt/go solution could persuade me to use it.
(not something like bridge between qt and go...if so, why not just use
c++? at least, i have qt creator)
On Monday, May 9, 2016 at 6:38:16 PM UTC+8, Egon wrote:
On Monday, 9 May 2016 13:19:30 UTC+3, Wang Yarco wrote:

I've heard something like someone developing GUI lib for golang. But
i doubt it, cause even Qt didn't achieve this (i mean, great success in
business. It just goes from one company to another. I like Qt). So i'm
thinking why google not purchase Qt? It seems tell them to do another
version of Qt in go not a big problem, no need reinvent it.

...Then i see golang is lack of event system. But if the future plan
of golang will include GUI part, it should have such event system like:

In Qt:
connect(from some object,clicked,to some object,func);

or even like in NodeJs/Js:
obj.on('clicked',func);

Or am i wrong?
Why? How many alternative approaches have you tried? Why do you assume
there exists a "one-size-fits-all-UI-solution"? :)

Also, you can already use Qt from Go (e.g.
https://github.com/go-qml/qml, https://github.com/therecipe/qt and
more
https://github.com/golang/go/wiki/projects#guis-and-widget-toolkits).

+ Egon
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 21 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 9, '16 at 10:19a
activeMay 12, '16 at 10:26a
posts21
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase