FAQ
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?
(Well, i have decided using go as my future main programming language. So
maybe expect it can do everything)

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

  • Egon at May 9, 2016 at 10:38 am

    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.
  • Wang Yarco at May 9, 2016 at 3:19 pm
    Well, i haven't tried everything. But that is the most elegant solution as
    i know.

    Em...though https://github.com/therecipe/qt 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.
  • Peter Herth at May 9, 2016 at 4:19 pm
    Why wouldn't these approaches work in Go? You can just pass the callback
    handler functions to the callbacks of the event generating objects. There
    is no need for an event system in the base language when your language has
    first-class functions. It then is just a matter of the API design of your
    library.

    I would though be quite happy if there was a simple to use and somewhat
    portable GUI for Go programs for at least some easy cases.

    Peter
    On Mon, May 9, 2016 at 5:19 PM, Wang Yarco wrote:

    Well, i haven't tried everything. But that is the most elegant solution as
    i know.

    Em...though https://github.com/therecipe/qt 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.
    --
    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.
  • Wang Yarco at May 9, 2016 at 4:45 pm
    " You can just pass the callback handler functions to the callbacks of the
    event generating objects"

    If you mean:

         btn.ConnectClicked(func(flag bool) {
             widgets.QMessageBox_Information(nil, "OK", "You Clicked me!", widgets.QMessageBox__Ok, widgets.QMessageBox__Ok)
         })


    That is the same thing in my mind as Nodejs/js style event system i
    previous mentioned.
    obj.on('clicked', func);
    But here, we are using Qt!!!

    How you do code when a value in a Struct changed, then trigger to execute
    something?
    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

    Of cause, there are solutions, but if no ember event system, what it would
    be like?

    On Tuesday, May 10, 2016 at 12:19:57 AM UTC+8, Peter Herth wrote:

    Why wouldn't these approaches work in Go? You can just pass the callback
    handler functions to the callbacks of the event generating objects. There
    is no need for an event system in the base language when your language has
    first-class functions. It then is just a matter of the API design of your
    library.

    I would though be quite happy if there was a simple to use and somewhat
    portable GUI for Go programs for at least some easy cases.

    Peter

    On Mon, May 9, 2016 at 5:19 PM, Wang Yarco <yarco...@gmail.com
    <javascript:>> wrote:
    Well, i haven't tried everything. But that is the most elegant solution
    as i know.

    Em...though https://github.com/therecipe/qt 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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
  • Egon at May 9, 2016 at 6:18 pm

    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.
  • Wang Yarco at May 10, 2016 at 12:33 am
    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)
    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.
    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.
  • Egon at May 10, 2016 at 5:36 am

    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.
  • Wang Yarco at May 10, 2016 at 12:52 pm
    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.
  • Egon at May 10, 2016 at 1:22 pm

    On Tuesday, 10 May 2016 15:52:48 UTC+3, Wang Yarco wrote:
    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).
    Chrome allows separating and merging tabs, each is a separate application.
    Not sure about the i

    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...
    Why not?

    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!
    Event systems are about:
    * Who will create the event,
    * who will define the events and
    * who will manage the events?

    // e.g.
    package event

    type Handler func(sender interface{}, message string, data interface{})

    type Emitter map[string][]Handler

    func (e Emitter) On(event string, fn Handler) {
    e[event] = append(e[event], fn)
    }

    func (e Emitter) Emit(source interface{}, message string, data interface{}){
    for _, fn := range e[message] {
    fn(source, message, data)
    }
    }

    var All map[string]Emitter = map[string]Emitter{}

    func Connect(source interface{}, message string, fn Handler) {
    //TODO: check, source must be a pointer
    e, ok := All[source]
    if !ok {
    e = Emitter{}
    All[source] = e
    }
    }

    func Emit(source interface{}, message string, data interface{}) {
    if e, ok := All[source]; ok {
    e.Emit(source, message, data)
    }
    }

    // usage 1

    type Lights struct {
    State bool
    }

    func (lights *Lights) Close() { event.Disconnect(lights) }
    func (lights *Lights) Toggle() {
    lights.State = !lights.State
    event.Emit(lights, "lights-changed", lights.State)
    }

    func main(){
    t := &Lights{}
    event.Connect(t, "lights-changed", func(source interface{}, message string,
    data interface{}){
    // ...
    })

    t.Toggle()
    t.Toggle()
    }

    // usage 2

    type Lights struct {
    Emitter
    State bool
    }

    func NewLights() *Lights { return &Lights{Emitter{}, false} }

    func (lights *Lights) Close() { lights.Emitter = nil }
    func (lights *Lights) Toggle() {
    lights.State = !lights.State
    lights.Emit(lights, "lights-changed", lights.State)
    }

    func main(){
    t := &Lights{}
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
    // ...
    })

    t.Toggle()
    t.Toggle()
    }

    *Obviously there are even more options.*
    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.
  • Wang Yarco at May 10, 2016 at 6:20 pm
    Chrome allows separating and merging tabs, each is a separate
    application. Not sure about the i
    I see. I haven't noticed that. I thought it is just like an MDI application
    under windows...Found multi-processed.
    Of cause, you are right in technical part.
    But as a human, it is cool to drag `activity monitor` into `chrome` as a
    chrome tab...And i think window manager is also a part of GUI system, no?

    I'm not going to define a callback func in the structure...
    >
    Why not?
    Freedom. :)
    Such style does mean all objects created by the structure have this
    feature. It is easy of cause when all objects do like to have this feature.
    But maybe some special objects don't want it, like me, in someway, as a
    Chinese, i'm a bit special. Maybe that's the reason, i don't want all
    objects do have same functions. Just free. I'm not sure. Maybe this answer
    comes from feeling, something more humanity.
    Event systems are about:...
    Yes, the usage 1 is what i want !!! I like the code!!!
    But if it is easy to do, why there's no such standard lib?

    And i'm thinking, there are also some extra things maybe:
    - how to perform `fn(source, message, data)` in Emit func
    func (e Emitter) Emit(source interface{}, message string, data interface{}){
        for _, fn := range e[message] {
             fn(source, message, data)
           }
    }
    What about use gorountines to executing dirty job?
    And of cause i can do it in the callback,
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
      go download_large_file...//some dirty work
    })
    But i don't want. I just want to supply a parameter that figure out the
    task should be done in an async way. That makes me feel more simple then
    add `go` before `download_large_file` process.
    t.On("lights-changed", DIRTY_WORK, func(source interface{}, message string,
    data interface{}){
      download_large_file...
    })
    And if there exists such a library can do the job, i even don't want to
    code more
    t.On("clicked",urlField.text, DIRTY_WORK,download_lib.download);
    So, actually, that is the Qt style then (without DIRTY_WORK)...seems more
    readable than anonymous callback function...
    - what about broadcasting? (or one signal send to lots objects)
    t.On('clicked',urlField.text,[[DIRTY_WORK,download_lib.download],[
    NOT_DIRTY_WORK,log.log]])
    (of cause, i can write a callback, but i also want some simple resolution)
    ... maybe others ...

    On Tuesday, May 10, 2016 at 9:22:14 PM UTC+8, Egon wrote:
    On Tuesday, 10 May 2016 15:52:48 UTC+3, Wang Yarco wrote:

    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).
    Chrome allows separating and merging tabs, each is a separate application.
    Not sure about the i

    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...
    Why not?

    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!
    Event systems are about:
    * Who will create the event,
    * who will define the events and
    * who will manage the events?

    // e.g.
    package event

    type Handler func(sender interface{}, message string, data interface{})

    type Emitter map[string][]Handler

    func (e Emitter) On(event string, fn Handler) {
    e[event] = append(e[event], fn)
    }

    func (e Emitter) Emit(source interface{}, message string, data
    interface{}){
    for _, fn := range e[message] {
    fn(source, message, data)
    }
    }

    var All map[string]Emitter = map[string]Emitter{}

    func Connect(source interface{}, message string, fn Handler) {
    //TODO: check, source must be a pointer
    e, ok := All[source]
    if !ok {
    e = Emitter{}
    All[source] = e
    }
    }

    func Emit(source interface{}, message string, data interface{}) {
    if e, ok := All[source]; ok {
    e.Emit(source, message, data)
    }
    }

    // usage 1

    type Lights struct {
    State bool
    }

    func (lights *Lights) Close() { event.Disconnect(lights) }
    func (lights *Lights) Toggle() {
    lights.State = !lights.State
    event.Emit(lights, "lights-changed", lights.State)
    }

    func main(){
    t := &Lights{}
    event.Connect(t, "lights-changed", func(source interface{}, message
    string, data interface{}){
    // ...
    })

    t.Toggle()
    t.Toggle()
    }

    // usage 2

    type Lights struct {
    Emitter
    State bool
    }

    func NewLights() *Lights { return &Lights{Emitter{}, false} }

    func (lights *Lights) Close() { lights.Emitter = nil }
    func (lights *Lights) Toggle() {
    lights.State = !lights.State
    lights.Emit(lights, "lights-changed", lights.State)
    }

    func main(){
    t := &Lights{}
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
    // ...
    })

    t.Toggle()
    t.Toggle()
    }

    *Obviously there are even more options.*
    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.
  • Egon at May 10, 2016 at 6:30 pm

    On Tuesday, 10 May 2016 21:20:20 UTC+3, Wang Yarco wrote:
    Chrome allows separating and merging tabs, each is a separate
    application. Not sure about the i
    I see. I haven't noticed that. I thought it is just like an MDI
    application under windows...Found multi-processed.
    Of cause, you are right in technical part.
    But as a human, it is cool to drag `activity monitor` into `chrome` as a
    chrome tab...And i think window manager is also a part of GUI system, no?

    I'm not going to define a callback func in the structure...

    Why not?
    Freedom. :)
    Such style does mean all objects created by the structure have this
    feature. It is easy of cause when all objects do like to have this feature.
    But maybe some special objects don't want it, like me, in someway, as a
    Chinese, i'm a bit special. Maybe that's the reason, i don't want all
    objects do have same functions. Just free. I'm not sure. Maybe this answer
    comes from feeling, something more humanity.
    Event systems are about:...
    Yes, the usage 1 is what i want !!! I like the code!!!
    But if it is easy to do, why there's no such standard lib?

    And i'm thinking, there are also some extra things maybe:
    - how to perform `fn(source, message, data)` in Emit func
    func (e Emitter) Emit(source interface{}, message string, data interface
    {}){
    for _, fn := range e[message] {
    fn(source, message, data)
    }
    }
    What about use gorountines to executing dirty job?
    And of cause i can do it in the callback,
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
    go download_large_file...//some dirty work
    })
    But i don't want. I just want to supply a parameter that figure out the
    task should be done in an async way. That makes me feel more simple then
    add `go` before `download_large_file` process.
    t.On("lights-changed", DIRTY_WORK, func(source interface{}, message string
    , data interface{}){
    download_large_file...
    })
    And if there exists such a library can do the job, i even don't want to
    code more
    t.On("clicked",urlField.text, DIRTY_WORK,download_lib.download);
    So, actually, that is the Qt style then (without DIRTY_WORK)...seems more
    readable than anonymous callback function...
    - what about broadcasting? (or one signal send to lots objects)
    t.On('clicked',urlField.text,[[DIRTY_WORK,download_lib.download],[
    NOT_DIRTY_WORK,log.log]])
    (of cause, i can write a callback, but i also want some simple resolution)
    ... maybe others ...
    Here's the answer to your own question.

    There are a lot of variations and possibilities how it can work and how it
    can be bound to other libraries. Basically, there is no universal solution
    and the best solution depends where it will be used. If there's not used
    somewhere, means there is no way to design a good event library.

    The event library and the UI library will always form a whole, i.e. you
    cannot design one without the other. Of course a UI library will need to
    take into account several real-world applications to ensure good design...

    + 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.
  • Pat Farrell at May 11, 2016 at 5:54 am

    On Tuesday, May 10, 2016 at 2:30:06 PM UTC-4, Egon wrote:
    s. Basically, there is no universal solution and the best solution depends
    where it will be used. If there's not used somewhere, means there is no way
    to design a good event library.
    The event library and the UI library will always form a whole, i.e. you
    cannot design one without the other. Of course a UI library will need to
    take into account several real-world applications to ensure good design...

    Sadly, in my 30+ years of writing GUI applications on many platforms and in
    many languages, I've seen a lot more poor libraries with poor design being
    used by many developers.

    I think it will be interesting to see how such libraries evolve in go. I
    love how simple go is, and how orthogonal its ideas are. Most GUI libraries
    are examples of excessive coupling.

    --
    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.
  • Egon at May 11, 2016 at 5:58 am

    On Wednesday, 11 May 2016 08:54:53 UTC+3, Pat Farrell wrote:
    On Tuesday, May 10, 2016 at 2:30:06 PM UTC-4, Egon wrote:

    s. Basically, there is no universal solution and the best solution
    depends where it will be used. If there's not used somewhere, means there
    is no way to design a good event library.
    The event library and the UI library will always form a whole, i.e. you
    cannot design one without the other. Of course a UI library will need to
    take into account several real-world applications to ensure good design...

    Sadly, in my 30+ years of writing GUI applications on many platforms and
    in many languages, I've seen a lot more poor libraries with poor design
    being used by many developers.
    Do you remember any interesting, special or some good ideas from some of
    them? Or parts that you really liked?

    I think it will be interesting to see how such libraries evolve in go. I
    love how simple go is, and how orthogonal its ideas are. Most GUI libraries
    are examples of excessive coupling.
    --
    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.
  • Wang Yarco at May 11, 2016 at 6:42 am
    Well, I'm going to code a simple event system based on your code to make
    myself feel happy on coding. Wish you don't mind.

    And, the GUI system, seems very complex to me for now, i can only give some
    ideas as i have written in your doc. Maybe i'm a little bit ideal.
    But think about VR, voice control, gesture, what will the future GUI system
    be? Sound n times harder than current system we have...
    Not sure the GUI system you talked here is for current or for future...And
    i'm also not sure it is the application feature or GUI:

    Case 1:
    - You draw a rect on some text when reading an PDF
    - You grab it and put it into another application

    Case 2:
    - You drag a white ball (virtual) and yellow color (together)
    - it becomes a yellow ball

    :) The only thing i'm sure, that is the human future.
    On Wednesday, May 11, 2016 at 2:30:06 AM UTC+8, Egon wrote:


    On Tuesday, 10 May 2016 21:20:20 UTC+3, Wang Yarco wrote:

    Chrome allows separating and merging tabs, each is a separate
    application. Not sure about the i
    I see. I haven't noticed that. I thought it is just like an MDI
    application under windows...Found multi-processed.
    Of cause, you are right in technical part.
    But as a human, it is cool to drag `activity monitor` into `chrome` as a
    chrome tab...And i think window manager is also a part of GUI system, no?

    I'm not going to define a callback func in the structure...

    Why not?
    Freedom. :)
    Such style does mean all objects created by the structure have this
    feature. It is easy of cause when all objects do like to have this feature.
    But maybe some special objects don't want it, like me, in someway, as a
    Chinese, i'm a bit special. Maybe that's the reason, i don't want all
    objects do have same functions. Just free. I'm not sure. Maybe this answer
    comes from feeling, something more humanity.
    Event systems are about:...
    Yes, the usage 1 is what i want !!! I like the code!!!
    But if it is easy to do, why there's no such standard lib?

    And i'm thinking, there are also some extra things maybe:
    - how to perform `fn(source, message, data)` in Emit func
    func (e Emitter) Emit(source interface{}, message string, data interface
    {}){
    for _, fn := range e[message] {
    fn(source, message, data)
    }
    }
    What about use gorountines to executing dirty job?
    And of cause i can do it in the callback,
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
    go download_large_file...//some dirty work
    })
    But i don't want. I just want to supply a parameter that figure out the
    task should be done in an async way. That makes me feel more simple then
    add `go` before `download_large_file` process.
    t.On("lights-changed", DIRTY_WORK, func(source interface{}, message
    string, data interface{}){
    download_large_file...
    })
    And if there exists such a library can do the job, i even don't want to
    code more
    t.On("clicked",urlField.text, DIRTY_WORK,download_lib.download);
    So, actually, that is the Qt style then (without DIRTY_WORK)...seems more
    readable than anonymous callback function...
    - what about broadcasting? (or one signal send to lots objects)
    t.On('clicked',urlField.text,[[DIRTY_WORK,download_lib.download],[
    NOT_DIRTY_WORK,log.log]])
    (of cause, i can write a callback, but i also want some simple resolution)
    ... maybe others ...
    Here's the answer to your own question.

    There are a lot of variations and possibilities how it can work and how it
    can be bound to other libraries. Basically, there is no universal solution
    and the best solution depends where it will be used. If there's not used
    somewhere, means there is no way to design a good event library.

    The event library and the UI library will always form a whole, i.e. you
    cannot design one without the other. Of course a UI library will need to
    take into account several real-world applications to ensure good design...

    + 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.
  • Egon at May 11, 2016 at 7:04 am

    On Wednesday, 11 May 2016 09:42:40 UTC+3, Wang Yarco wrote:
    Well, I'm going to code a simple event system based on your code to make
    myself feel happy on coding. Wish you don't mind.

    And, the GUI system, seems very complex to me for now,
    Try to write one, it's not too complicated to write a basic UI library...

    just, break it down:

    1. write code that draws a colored rectangle on the screen
    2. change the color based on the cursor position
    3. change the color of the rect when the mouse button is pressed
    4. write code for coloring and activating multiple buttons
    5. write code to use a callback when button is pressed
    6. write code to dispatch an event when button is pressed
    7. write a control that allows automatically layouting several buttons in a
    grid
    8. write code that puts text on the button
    9. write code to handle keyboard focus

    You might need some additional steps and try several ways of writing each
    step.

    i can only give some ideas as i have written in your doc. Maybe i'm a
    little bit ideal.
    But think about VR, voice control, gesture, what will the future GUI
    system be? Sound n times harder than current system we have...
    Not sure the GUI system you talked here is for current or for future...
    There isn't a universal solution. Every time you make a decision to support
    something or not support something, you will be making trade-offs. The best
    trade-offs will vary depending on the situation. The doc is more about
    collecting the different trade-offs that each system makes, rather than to
    find the "universal" solution. Based on that information make a "good
    enough for most cases" similarly to how most Go code is... but still leave
    interesting ideas for the niches.

    And i'm also not sure it is the application feature or GUI:
    Case 1:
    - You draw a rect on some text when reading an PDF
    - You grab it and put it into another application

    Case 2:
    - You drag a white ball (virtual) and yellow color (together)
    - it becomes a yellow ball

    :) The only thing i'm sure, that is the human future.
    On Wednesday, May 11, 2016 at 2:30:06 AM UTC+8, Egon wrote:


    On Tuesday, 10 May 2016 21:20:20 UTC+3, Wang Yarco wrote:

    Chrome allows separating and merging tabs, each is a separate
    application. Not sure about the i
    I see. I haven't noticed that. I thought it is just like an MDI
    application under windows...Found multi-processed.
    Of cause, you are right in technical part.
    But as a human, it is cool to drag `activity monitor` into `chrome` as a
    chrome tab...And i think window manager is also a part of GUI system, no?

    I'm not going to define a callback func in the structure...

    Why not?
    Freedom. :)
    Such style does mean all objects created by the structure have this
    feature. It is easy of cause when all objects do like to have this feature.
    But maybe some special objects don't want it, like me, in someway, as a
    Chinese, i'm a bit special. Maybe that's the reason, i don't want all
    objects do have same functions. Just free. I'm not sure. Maybe this answer
    comes from feeling, something more humanity.
    Event systems are about:...
    Yes, the usage 1 is what i want !!! I like the code!!!
    But if it is easy to do, why there's no such standard lib?

    And i'm thinking, there are also some extra things maybe:
    - how to perform `fn(source, message, data)` in Emit func
    func (e Emitter) Emit(source interface{}, message string, data interface
    {}){
    for _, fn := range e[message] {
    fn(source, message, data)
    }
    }
    What about use gorountines to executing dirty job?
    And of cause i can do it in the callback,
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
    go download_large_file...//some dirty work
    })
    But i don't want. I just want to supply a parameter that figure out the
    task should be done in an async way. That makes me feel more simple then
    add `go` before `download_large_file` process.
    t.On("lights-changed", DIRTY_WORK, func(source interface{}, message
    string, data interface{}){
    download_large_file...
    })
    And if there exists such a library can do the job, i even don't want to
    code more
    t.On("clicked",urlField.text, DIRTY_WORK,download_lib.download);
    So, actually, that is the Qt style then (without DIRTY_WORK)...seems
    more readable than anonymous callback function...
    - what about broadcasting? (or one signal send to lots objects)
    t.On('clicked',urlField.text,[[DIRTY_WORK,download_lib.download],[
    NOT_DIRTY_WORK,log.log]])
    (of cause, i can write a callback, but i also want some simple
    resolution)
    ... maybe others ...
    Here's the answer to your own question.

    There are a lot of variations and possibilities how it can work and how
    it can be bound to other libraries. Basically, there is no universal
    solution and the best solution depends where it will be used. If there's
    not used somewhere, means there is no way to design a good event library.

    The event library and the UI library will always form a whole, i.e. you
    cannot design one without the other. Of course a UI library will need to
    take into account several real-world applications to ensure good design...

    + 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.
  • Wang Yarco at May 11, 2016 at 1:58 pm
    Just copied your steps into my notes. If possible, will do practise one
    day, for learning purpose.
    (do you mean using golang? i'm not sure...but if in c++, and if using
    opengl for example, they are just too far from my normal life.
    I'm a web developer, http://www.bbish.net/langs.html that's my target
    area)

    And for those advanced ideas, i think it would be better to get
    Apple/Microsoft/Google worry about that...
    Except they hire me as the product manager or something what, just tell
    them the ideas, that is the thing i can do. :)
    For now i'm just care about the event system.
    On Wednesday, May 11, 2016 at 3:04:26 PM UTC+8, Egon wrote:
    On Wednesday, 11 May 2016 09:42:40 UTC+3, Wang Yarco wrote:

    Well, I'm going to code a simple event system based on your code to make
    myself feel happy on coding. Wish you don't mind.

    And, the GUI system, seems very complex to me for now,
    Try to write one, it's not too complicated to write a basic UI library...

    just, break it down:

    1. write code that draws a colored rectangle on the screen
    2. change the color based on the cursor position
    3. change the color of the rect when the mouse button is pressed
    4. write code for coloring and activating multiple buttons
    5. write code to use a callback when button is pressed
    6. write code to dispatch an event when button is pressed
    7. write a control that allows automatically layouting several buttons in
    a grid
    8. write code that puts text on the button
    9. write code to handle keyboard focus

    You might need some additional steps and try several ways of writing each
    step.

    i can only give some ideas as i have written in your doc. Maybe i'm a
    little bit ideal.
    But think about VR, voice control, gesture, what will the future GUI
    system be? Sound n times harder than current system we have...
    Not sure the GUI system you talked here is for current or for future...
    There isn't a universal solution. Every time you make a decision to
    support something or not support something, you will be making trade-offs.
    The best trade-offs will vary depending on the situation. The doc is more
    about collecting the different trade-offs that each system makes, rather
    than to find the "universal" solution. Based on that information make a
    "good enough for most cases" similarly to how most Go code is... but still
    leave interesting ideas for the niches.

    And i'm also not sure it is the application feature or GUI:
    Case 1:
    - You draw a rect on some text when reading an PDF
    - You grab it and put it into another application

    Case 2:
    - You drag a white ball (virtual) and yellow color (together)
    - it becomes a yellow ball

    :) The only thing i'm sure, that is the human future.
    On Wednesday, May 11, 2016 at 2:30:06 AM UTC+8, Egon wrote:


    On Tuesday, 10 May 2016 21:20:20 UTC+3, Wang Yarco wrote:

    Chrome allows separating and merging tabs, each is a separate
    application. Not sure about the i
    I see. I haven't noticed that. I thought it is just like an MDI
    application under windows...Found multi-processed.
    Of cause, you are right in technical part.
    But as a human, it is cool to drag `activity monitor` into `chrome` as
    a chrome tab...And i think window manager is also a part of GUI system, no?

    I'm not going to define a callback func in the structure...

    Why not?
    Freedom. :)
    Such style does mean all objects created by the structure have this
    feature. It is easy of cause when all objects do like to have this feature.
    But maybe some special objects don't want it, like me, in someway, as a
    Chinese, i'm a bit special. Maybe that's the reason, i don't want all
    objects do have same functions. Just free. I'm not sure. Maybe this answer
    comes from feeling, something more humanity.
    Event systems are about:...
    Yes, the usage 1 is what i want !!! I like the code!!!
    But if it is easy to do, why there's no such standard lib?

    And i'm thinking, there are also some extra things maybe:
    - how to perform `fn(source, message, data)` in Emit func
    func (e Emitter) Emit(source interface{}, message string, data
    interface{}){
    for _, fn := range e[message] {
    fn(source, message, data)
    }
    }
    What about use gorountines to executing dirty job?
    And of cause i can do it in the callback,
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
    go download_large_file...//some dirty work
    })
    But i don't want. I just want to supply a parameter that figure out the
    task should be done in an async way. That makes me feel more simple then
    add `go` before `download_large_file` process.
    t.On("lights-changed", DIRTY_WORK, func(source interface{}, message
    string, data interface{}){
    download_large_file...
    })
    And if there exists such a library can do the job, i even don't want to
    code more
    t.On("clicked",urlField.text, DIRTY_WORK,download_lib.download);
    So, actually, that is the Qt style then (without DIRTY_WORK)...seems
    more readable than anonymous callback function...
    - what about broadcasting? (or one signal send to lots objects)
    t.On('clicked',urlField.text,[[DIRTY_WORK,download_lib.download],[
    NOT_DIRTY_WORK,log.log]])
    (of cause, i can write a callback, but i also want some simple
    resolution)
    ... maybe others ...
    Here's the answer to your own question.

    There are a lot of variations and possibilities how it can work and how
    it can be bound to other libraries. Basically, there is no universal
    solution and the best solution depends where it will be used. If there's
    not used somewhere, means there is no way to design a good event library.

    The event library and the UI library will always form a whole, i.e. you
    cannot design one without the other. Of course a UI library will need to
    take into account several real-world applications to ensure good design...

    + 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.
  • Egon at May 12, 2016 at 10:26 am

    On Wednesday, 11 May 2016 16:58:36 UTC+3, Wang Yarco wrote:
    Just copied your steps into my notes. If possible, will do practise one
    day, for learning purpose.
    (do you mean using golang? i'm not sure...but if in c++, and if using
    opengl for example, they are just too far from my normal life.
    I'm a web developer, http://www.bbish.net/langs.html that's my target
    area)
    Doesn't really matter what you use. For you I would suggest JS + Canvas.

    --
    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.
  • Michael Jones at May 11, 2016 at 7:14 am
    The UI infrastructure in Smalltalk (Morphic) is a masterpiece of
    generality, composability, and mutability. Learn from that (squeak.org) if
    you want deep insight into design in this area.

    Alan Kay has often shared that messages were the greater innovation than
    the windowing system, the mouse, and the rest. Learn from that too.

    Michael
    Well, I'm going to code a simple event system based on your code to make
    myself feel happy on coding. Wish you don't mind.

    And, the GUI system, seems very complex to me for now, i can only give some
    ideas as i have written in your doc. Maybe i'm a little bit ideal.
    But think about VR, voice control, gesture, what will the future GUI system
    be? Sound n times harder than current system we have...
    Not sure the GUI system you talked here is for current or for future...And
    i'm also not sure it is the application feature or GUI:

    Case 1:
    - You draw a rect on some text when reading an PDF
    - You grab it and put it into another application

    Case 2:
    - You drag a white ball (virtual) and yellow color (together)
    - it becomes a yellow ball

    :) The only thing i'm sure, that is the human future.
    On Wednesday, May 11, 2016 at 2:30:06 AM UTC+8, Egon wrote:


    On Tuesday, 10 May 2016 21:20:20 UTC+3, Wang Yarco wrote:

    Chrome allows separating and merging tabs, each is a separate
    application. Not sure about the i
    I see. I haven't noticed that. I thought it is just like an MDI
    application under windows...Found multi-processed.
    Of cause, you are right in technical part.
    But as a human, it is cool to drag `activity monitor` into `chrome` as a
    chrome tab...And i think window manager is also a part of GUI system, no?

    I'm not going to define a callback func in the structure...

    Why not?
    Freedom. :)
    Such style does mean all objects created by the structure have this
    feature. It is easy of cause when all objects do like to have this feature.
    But maybe some special objects don't want it, like me, in someway, as a
    Chinese, i'm a bit special. Maybe that's the reason, i don't want all
    objects do have same functions. Just free. I'm not sure. Maybe this answer
    comes from feeling, something more humanity.
    Event systems are about:...
    Yes, the usage 1 is what i want !!! I like the code!!!
    But if it is easy to do, why there's no such standard lib?

    And i'm thinking, there are also some extra things maybe:
    - how to perform `fn(source, message, data)` in Emit func
    func (e Emitter) Emit(source interface{}, message string, data interface
    {}){
    for _, fn := range e[message] {
    fn(source, message, data)
    }
    }
    What about use gorountines to executing dirty job?
    And of cause i can do it in the callback,
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
    go download_large_file...//some dirty work
    })
    But i don't want. I just want to supply a parameter that figure out the
    task should be done in an async way. That makes me feel more simple then
    add `go` before `download_large_file` process.
    t.On("lights-changed", DIRTY_WORK, func(source interface{}, message
    string, data interface{}){
    download_large_file...
    })
    And if there exists such a library can do the job, i even don't want to
    code more
    t.On("clicked",urlField.text, DIRTY_WORK,download_lib.download);
    So, actually, that is the Qt style then (without DIRTY_WORK)...seems more
    readable than anonymous callback function...
    - what about broadcasting? (or one signal send to lots objects)
    t.On('clicked',urlField.text,[[DIRTY_WORK,download_lib.download],[
    NOT_DIRTY_WORK,log.log]])
    (of cause, i can write a callback, but i also want some simple resolution)
    ... maybe others ...
    Here's the answer to your own question.

    There are a lot of variations and possibilities how it can work and how it
    can be bound to other libraries. Basically, there is no universal solution
    and the best solution depends where it will be used. If there's not used
    somewhere, means there is no way to design a good event library.

    The event library and the UI library will always form a whole, i.e. you
    cannot design one without the other. Of course a UI library will need to
    take into account several real-world applications to ensure good design...

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

    --
    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.
  • Egon at May 11, 2016 at 7:53 am

    On Wednesday, 11 May 2016 10:15:11 UTC+3, Michael Jones wrote:
    The UI infrastructure in Smalltalk (Morphic) is a masterpiece of
    generality, composability, and mutability.
    Based on limited experience, the main annoyance I felt when trying Morphic
    was that it used extensively inheritance and it fragmented the component
    logic and implementation -- i.e. it was hard to figure out what is the
    whole component. Most inheritance based approaches (i.e. all that I've
    seen) share the same problem. I'm guessing the Morphic approach would
    become clearer and more composable by merging it with ECS or BOT approach.

    The other problem with such retained approaches that there is clear ground
    truth. *e.g. a slider emits an event that you modified something, in the
    event handler you modify the state... alternatively, something causes your
    state to be modified and now you have to move the slider.*

    But still, I agree, Morphic is one of the best retained approaches I've
    seen. The design is clean and well structured. However, it never felt
    completely alive *(in the Alexandrian sense)*.

    *PS: Morphic originated from Self, and for more information on the
    internals*
    * * http://wiki.squeak.org/squeak/2139*
    * * http://handbook.selflanguage.org/current/morphic.html*
    * * http://wiki.squeak.org/squeak/1285, http://wiki.squeak.org/squeak/1820*

    Learn from that (squeak.org
    <http://www.google.com/url?q=http%3A%2F%2Fsqueak.org&sa=D&sntz=1&usg=AFQjCNHOFYPpYjVtKbdpj3wPGW-BCayQNw>)
    if you want deep insight into design in this area.

    Alan Kay has often shared that messages were the greater innovation than
    the windowing system, the mouse, and the rest. Learn from that too.

    Michael
    Well, I'm going to code a simple event system based on your code to make
    myself feel happy on coding. Wish you don't mind.

    And, the GUI system, seems very complex to me for now, i can only give
    some ideas as i have written in your doc. Maybe i'm a little bit ideal.
    But think about VR, voice control, gesture, what will the future GUI
    system be? Sound n times harder than current system we have...
    Not sure the GUI system you talked here is for current or for future...And
    i'm also not sure it is the application feature or GUI:

    Case 1:
    - You draw a rect on some text when reading an PDF
    - You grab it and put it into another application

    Case 2:
    - You drag a white ball (virtual) and yellow color (together)
    - it becomes a yellow ball

    :) The only thing i'm sure, that is the human future.
    On Wednesday, May 11, 2016 at 2:30:06 AM UTC+8, Egon wrote:


    On Tuesday, 10 May 2016 21:20:20 UTC+3, Wang Yarco wrote:

    Chrome allows separating and merging tabs, each is a separate
    application. Not sure about the i
    I see. I haven't noticed that. I thought it is just like an MDI
    application under windows...Found multi-processed.
    Of cause, you are right in technical part.
    But as a human, it is cool to drag `activity monitor` into `chrome` as a
    chrome tab...And i think window manager is also a part of GUI system, no?

    I'm not going to define a callback func in the structure...

    Why not?
    Freedom. :)
    Such style does mean all objects created by the structure have this
    feature. It is easy of cause when all objects do like to have this feature.
    But maybe some special objects don't want it, like me, in someway, as a
    Chinese, i'm a bit special. Maybe that's the reason, i don't want all
    objects do have same functions. Just free. I'm not sure. Maybe this answer
    comes from feeling, something more humanity.
    Event systems are about:...
    Yes, the usage 1 is what i want !!! I like the code!!!
    But if it is easy to do, why there's no such standard lib?

    And i'm thinking, there are also some extra things maybe:
    - how to perform `fn(source, message, data)` in Emit func
    func (e Emitter) Emit(source interface{}, message string, data interface
    {}){
    for _, fn := range e[message] {
    fn(source, message, data)
    }
    }
    What about use gorountines to executing dirty job?
    And of cause i can do it in the callback,
    t.On("lights-changed", func(source interface{}, message string, data
    interface{}){
    go download_large_file...//some dirty work
    })
    But i don't want. I just want to supply a parameter that figure out the
    task should be done in an async way. That makes me feel more simple then
    add `go` before `download_large_file` process.
    t.On("lights-changed", DIRTY_WORK, func(source interface{}, message
    string, data interface{}){
    download_large_file...
    })
    And if there exists such a library can do the job, i even don't want to
    code more
    t.On("clicked",urlField.text, DIRTY_WORK,download_lib.download);
    So, actually, that is the Qt style then (without DIRTY_WORK)...seems
    more readable than anonymous callback function...
    - what about broadcasting? (or one signal send to lots objects)
    t.On('clicked',urlField.text,[[DIRTY_WORK,download_lib.download],[
    NOT_DIRTY_WORK,log.log]])
    (of cause, i can write a callback, but i also want some simple
    resolution)
    ... maybe others ...
    Here's the answer to your own question.

    There are a lot of variations and possibilities how it can work and how
    it can be bound to other libraries. Basically, there is no universal
    solution and the best solution depends where it will be used. If there's
    not used somewhere, means there is no way to design a good event library.

    The event library and the UI library will always form a whole, i.e. you
    cannot design one without the other. Of course a UI library will need to
    take into account several real-world applications to ensure good design...

    + 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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
  • Wang Yarco at May 10, 2016 at 12:58 am
    Also +
    Future consideration: the GUI system should keep future technologies in
    mind, like voice control, gesture
    in `thoughts` section in your doc. :)
    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.

Related Discussions

Discussion Navigation
viewthread | post
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