Most examples in 'examples/GUI examples' do not work #560

Closed
scztt opened this Issue Oct 3, 2012 · 15 comments

Comments

Projects
None yet
10 participants
@scztt
Contributor

scztt commented Oct 3, 2012

Nearly none of the examples in 'examples/GUI examples' work out of the box. Some work with trivial modifications. Some invoke objects that are not implemented in GUI.qt

These should be removed, or fixed if they are going to be left in - they're the first thing a new user will try, they should work out of the box.

@timblechmann

This comment has been minimized.

Show comment Hide comment
@timblechmann

timblechmann Oct 3, 2012

Contributor

since you were looking at it, which examples do not work?

Contributor

timblechmann commented Oct 3, 2012

since you were looking at it, which examples do not work?

@scztt

This comment has been minimized.

Show comment Hide comment
@scztt

scztt Oct 3, 2012

Contributor
  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser, scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which should probably be removed.

Contributor

scztt commented Oct 3, 2012

  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser, scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which should probably be removed.

@scztt

This comment has been minimized.

Show comment Hide comment
@scztt

scztt Oct 3, 2012

Contributor

There may be other things in examples/* which have issues, I haven't tried - I just happened to grab the alpha today on a machine with no SC code handly, so I quickly went through the gui examples and noticed the above.

Contributor

scztt commented Oct 3, 2012

There may be other things in examples/* which have issues, I haven't tried - I just happened to grab the alpha today on a machine with no SC code handly, so I quickly went through the gui examples and noticed the above.

@sensestage

This comment has been minimized.

Show comment Hide comment
@sensestage

sensestage Oct 4, 2012

Contributor

On Wednesday 03 October 2012 09:52:42 scztt wrote:

  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser,
    scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which
should probably be removed.

There will still be usecases for GUI.swing in the future (e.g. running a GUI
on another machine).

sincerely,
Marije

Contributor

sensestage commented Oct 4, 2012

On Wednesday 03 October 2012 09:52:42 scztt wrote:

  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser,
    scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which
should probably be removed.

There will still be usecases for GUI.swing in the future (e.g. running a GUI
on another machine).

sincerely,
Marije

@scztt

This comment has been minimized.

Show comment Hide comment
@scztt

scztt Oct 4, 2012

Contributor

I definitely agree - I don't think they should be needed for basic GUI examples though? From a new user perspective, - opening one of those example files and running the first and second line are both going to result in somewhat opaque GUI scheme errors.

Contributor

scztt commented Oct 4, 2012

I definitely agree - I don't think they should be needed for basic GUI examples though? From a new user perspective, - opening one of those example files and running the first and second line are both going to result in somewhat opaque GUI scheme errors.

@jamshark70

This comment has been minimized.

Show comment Hide comment
@jamshark70

jamshark70 Oct 4, 2012

Contributor

analog-drum-tuner contains no reference to cocoa or swing, and it does not fail. There was a warning about using a deprecated class, but the GUI comes up correctly for me in 3.6.

I have fixed the deprecation warning just now (ddbe4d0).

Contributor

jamshark70 commented Oct 4, 2012

analog-drum-tuner contains no reference to cocoa or swing, and it does not fail. There was a warning about using a deprecated class, but the GUI comes up correctly for me in 3.6.

I have fixed the deprecation warning just now (ddbe4d0).

@timblechmann

This comment has been minimized.

Show comment Hide comment
@timblechmann

timblechmann Oct 4, 2012

Contributor
  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser,
    scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which
should probably be removed.

There will still be usecases for GUI.swing in the future (e.g. running a GUI
on another machine).

the question is, if we should support it. talking with sciss during
icmc, i became the impression that he does not really maintain it any
more ... with means that it won't ever support things like layouts,
which means that we cannot use layouts or palettes in any gui of the
main class library ... which is a shame as some of them are really ugly ...

Contributor

timblechmann commented Oct 4, 2012

  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser,
    scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which
should probably be removed.

There will still be usecases for GUI.swing in the future (e.g. running a GUI
on another machine).

the question is, if we should support it. talking with sciss during
icmc, i became the impression that he does not really maintain it any
more ... with means that it won't ever support things like layouts,
which means that we cannot use layouts or palettes in any gui of the
main class library ... which is a shame as some of them are really ugly ...

@sensestage

This comment has been minimized.

Show comment Hide comment
@sensestage

sensestage Oct 5, 2012

Contributor

On Thursday 04 October 2012 09:55:59 Tim Blechmann wrote:

  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser,
    scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which
should probably be removed.

There will still be usecases for GUI.swing in the future (e.g. running a
GUI on another machine).

the question is, if we should support it. talking with sciss during
icmc, i became the impression that he does not really maintain it any
more ... with means that it won't ever support things like layouts,
which means that we cannot use layouts or palettes in any gui of the
main class library ... which is a shame as some of them are really ugly ...

I think the layout stuff would not be too hard to add to SwingOSC, I think
those concepts are part of the Swing GUI system (I guess, they are quite
natural for GUI toolkits, I believe; I always thought it was a shame to loose
them when SCUM was no longer maintained...).

In any case we could keep the old implementations in some way (move to a quark
if need be) so they can still be used by those who want.

sincerely,
Marije

Contributor

sensestage commented Oct 5, 2012

On Thursday 04 October 2012 09:55:59 Tim Blechmann wrote:

  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser,
    scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which
should probably be removed.

There will still be usecases for GUI.swing in the future (e.g. running a
GUI on another machine).

the question is, if we should support it. talking with sciss during
icmc, i became the impression that he does not really maintain it any
more ... with means that it won't ever support things like layouts,
which means that we cannot use layouts or palettes in any gui of the
main class library ... which is a shame as some of them are really ugly ...

I think the layout stuff would not be too hard to add to SwingOSC, I think
those concepts are part of the Swing GUI system (I guess, they are quite
natural for GUI toolkits, I believe; I always thought it was a shame to loose
them when SCUM was no longer maintained...).

In any case we could keep the old implementations in some way (move to a quark
if need be) so they can still be used by those who want.

sincerely,
Marije

@muellmusik

This comment has been minimized.

Show comment Hide comment
@muellmusik

muellmusik Oct 5, 2012

Contributor

On 5 Oct 2012, at 09:51, sensestage wrote:

On Thursday 04 October 2012 09:55:59 Tim Blechmann wrote:

  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser,
    scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which
should probably be removed.

There will still be usecases for GUI.swing in the future (e.g. running a
GUI on another machine).

the question is, if we should support it. talking with sciss during
icmc, i became the impression that he does not really maintain it any
more ... with means that it won't ever support things like layouts,
which means that we cannot use layouts or palettes in any gui of the
main class library ... which is a shame as some of them are really ugly ...

I think the layout stuff would not be too hard to add to SwingOSC, I think
those concepts are part of the Swing GUI system (I guess, they are quite
natural for GUI toolkits, I believe; I always thought it was a shame to loose
them when SCUM was no longer maintained...).

In any case we could keep the old implementations in some way (move to a quark
if need be) so they can still be used by those who want.

Longer term, it might be nice to abstract the Qt GUI API so as to allow for different types of communication. I seem to recall it was pretty modularised anyway, but Jakob can tell me if I'm just going nuts.

That could allow for things like GUI servers on other machines, (the option at least of) GUI widgets within the IDE while still maintaining a separate sclang, whatever.

Even as it is, it wouldn't be too hard to write a class library to allow GUI communication between sclangs on different machines. The bits are all there (e.g. felix's API), you'd just need to make it easy to switch. Then you could just have

GUI.qtremote
QtRemoteGUI.setRemoteIP

and the appropriate counter settings on the other machine.

Of course still could be issues with synchronous methods, but that's a problem with SwingOSC now.

S.

Contributor

muellmusik commented Oct 5, 2012

On 5 Oct 2012, at 09:51, sensestage wrote:

On Thursday 04 October 2012 09:55:59 Tim Blechmann wrote:

  • rotary hommage duchamp.scd - works
  • Nick's LetterGimmick.scd - works
  • Gui_examples* - mostly work, few things not supported
  • TwoMultislidersInOne.scd - works, possibly with issues
  • The remaining fail with errors (analog-drum-tuner, ColorBrowser,
    scimage_animation, ScopeExample, SCScope view, strike)

All of the above contain references to GUI.cocoa and GUI.swing, which
should probably be removed.

There will still be usecases for GUI.swing in the future (e.g. running a
GUI on another machine).

the question is, if we should support it. talking with sciss during
icmc, i became the impression that he does not really maintain it any
more ... with means that it won't ever support things like layouts,
which means that we cannot use layouts or palettes in any gui of the
main class library ... which is a shame as some of them are really ugly ...

I think the layout stuff would not be too hard to add to SwingOSC, I think
those concepts are part of the Swing GUI system (I guess, they are quite
natural for GUI toolkits, I believe; I always thought it was a shame to loose
them when SCUM was no longer maintained...).

In any case we could keep the old implementations in some way (move to a quark
if need be) so they can still be used by those who want.

Longer term, it might be nice to abstract the Qt GUI API so as to allow for different types of communication. I seem to recall it was pretty modularised anyway, but Jakob can tell me if I'm just going nuts.

That could allow for things like GUI servers on other machines, (the option at least of) GUI widgets within the IDE while still maintaining a separate sclang, whatever.

Even as it is, it wouldn't be too hard to write a class library to allow GUI communication between sclangs on different machines. The bits are all there (e.g. felix's API), you'd just need to make it easy to switch. Then you could just have

GUI.qtremote
QtRemoteGUI.setRemoteIP

and the appropriate counter settings on the other machine.

Of course still could be issues with synchronous methods, but that's a problem with SwingOSC now.

S.

@jleben

This comment has been minimized.

Show comment Hide comment
@jleben

jleben Oct 5, 2012

Member

Longer term, it might be nice to abstract the Qt GUI API so as to allow for different types of communication. I seem to recall it was pretty modularised anyway

Yes, that's true. Qt GUI implementation consists of SC class, C++ classes, and a thin C++ layer in between that does the communication. By using Qt's introspection, the methods of C++ classes can be called without them knowing anything about their context, so the communication layer could easily be replaced with another system.

Of course still could be issues with synchronous methods, but that's a problem with SwingOSC now.

I've tried to deal with this in the early days of Qt GUI when trying to allow the use of GUI from any SC thread. And this turned out to be quite a big challenge! All the respect to Sciss for succeeding to satisfy synchronous API with asynchronous implementation. But I think it would be a lot of work until we can manage to do that with Qt GUI and bug-free.

Member

jleben commented Oct 5, 2012

Longer term, it might be nice to abstract the Qt GUI API so as to allow for different types of communication. I seem to recall it was pretty modularised anyway

Yes, that's true. Qt GUI implementation consists of SC class, C++ classes, and a thin C++ layer in between that does the communication. By using Qt's introspection, the methods of C++ classes can be called without them knowing anything about their context, so the communication layer could easily be replaced with another system.

Of course still could be issues with synchronous methods, but that's a problem with SwingOSC now.

I've tried to deal with this in the early days of Qt GUI when trying to allow the use of GUI from any SC thread. And this turned out to be quite a big challenge! All the respect to Sciss for succeeding to satisfy synchronous API with asynchronous implementation. But I think it would be a lot of work until we can manage to do that with Qt GUI and bug-free.

@muellmusik

This comment has been minimized.

Show comment Hide comment
@muellmusik

muellmusik Oct 5, 2012

Contributor

On 5 Oct 2012, at 10:23, Jakob Leben wrote:

Longer term, it might be nice to abstract the Qt GUI API so as to allow for different types of communication. I seem to recall it was pretty modularised anyway

Yes, that's true. Qt GUI implementation consists of SC class, C++ classes, and a thin C++ layer in between that does the communication. By using Qt's introspection, the methods of C++ classes can be called without them knowing anything about their context, so the communication layer could easily be replaced with another system.

A very good design choice! :-) It's a pleasure to even think about that, I have to say!
Of course still could be issues with synchronous methods, but that's a problem with SwingOSC now.

I've tried to deal with this in the early days of Qt GUI when trying to allow the use of GUI from any SC thread. And this turned out to be quite a big challenge! All the respect to Sciss for succeeding to satisfy synchronous API with asynchronous implementation. But I think it would be a lot of work until we can manage to do that with Qt GUI and bug-free.

I don't know that SwingOSC was totally successful in this regard, but in most cases of course it doesn't matter so much as long as the GUI server handles commands in order, and a certain amount of bookkeeping is done client-side. The problem occurred with things like String:bounds, which really expected a synchronous response.

I remember when all this was discussed some time back JMC said that if he was redoing it he'd just make everything for GUIs asynchronous.

Contributor

muellmusik commented Oct 5, 2012

On 5 Oct 2012, at 10:23, Jakob Leben wrote:

Longer term, it might be nice to abstract the Qt GUI API so as to allow for different types of communication. I seem to recall it was pretty modularised anyway

Yes, that's true. Qt GUI implementation consists of SC class, C++ classes, and a thin C++ layer in between that does the communication. By using Qt's introspection, the methods of C++ classes can be called without them knowing anything about their context, so the communication layer could easily be replaced with another system.

A very good design choice! :-) It's a pleasure to even think about that, I have to say!
Of course still could be issues with synchronous methods, but that's a problem with SwingOSC now.

I've tried to deal with this in the early days of Qt GUI when trying to allow the use of GUI from any SC thread. And this turned out to be quite a big challenge! All the respect to Sciss for succeeding to satisfy synchronous API with asynchronous implementation. But I think it would be a lot of work until we can manage to do that with Qt GUI and bug-free.

I don't know that SwingOSC was totally successful in this regard, but in most cases of course it doesn't matter so much as long as the GUI server handles commands in order, and a certain amount of bookkeeping is done client-side. The problem occurred with things like String:bounds, which really expected a synchronous response.

I remember when all this was discussed some time back JMC said that if he was redoing it he'd just make everything for GUIs asynchronous.

@jleben

This comment has been minimized.

Show comment Hide comment
@jleben

jleben Oct 5, 2012

Member

I remember when all this was discussed some time back JMC said that if he was redoing it he'd just make everything for GUIs asynchronous.

And actually, my plan for SC 3.7 is to introduce support for Qt GUIs created in QML. All code that defines the GUI elements, as well as their interrelations, would happen in QML. So the SC language part would be greatly minimized to only providing musical information to GUI, and responding to GUI events when really necessary for the sake of music control. This would allow the SC <-> GUI communication to be strictly asynchronous without much practical disadvantage, and hence completely real-time safe, and which much fewer and smaller interruptions of SC language.

Member

jleben commented Oct 5, 2012

I remember when all this was discussed some time back JMC said that if he was redoing it he'd just make everything for GUIs asynchronous.

And actually, my plan for SC 3.7 is to introduce support for Qt GUIs created in QML. All code that defines the GUI elements, as well as their interrelations, would happen in QML. So the SC language part would be greatly minimized to only providing musical information to GUI, and responding to GUI events when really necessary for the sake of music control. This would allow the SC <-> GUI communication to be strictly asynchronous without much practical disadvantage, and hence completely real-time safe, and which much fewer and smaller interruptions of SC language.

@timblechmann

This comment has been minimized.

Show comment Hide comment
@timblechmann

timblechmann Oct 7, 2012

Contributor

this might need some further cleanup ... and imo a lot of these examples should move to the help system ... also to reduce the scattering of the documentation

Contributor

timblechmann commented Oct 7, 2012

this might need some further cleanup ... and imo a lot of these examples should move to the help system ... also to reduce the scattering of the documentation

@scztt scztt modified the milestone: 3.7 Apr 18, 2015

@scztt scztt added the bug label Apr 19, 2015

@crucialfelix crucialfelix modified the milestones: 3.7.x, 3.8 Mar 14, 2016

@vivid-synth

This comment has been minimized.

Show comment Hide comment
@vivid-synth

vivid-synth Aug 1, 2016

Member

(can we add the "comp: QT GUI" label to this?)

Member

vivid-synth commented Aug 1, 2016

(can we add the "comp: QT GUI" label to this?)

@snappizz snappizz modified the milestones: 3.8, 3.9 Jan 15, 2017

telephon added a commit to telephon/supercollider that referenced this issue Jan 15, 2017

telephon added a commit to telephon/supercollider that referenced this issue Jan 16, 2017

@brianlheim brianlheim closed this in #2653 Jan 31, 2017

@snappizz

This comment has been minimized.

Show comment Hide comment
@snappizz

snappizz Jan 31, 2017

Member

What about #2329? I forgot exactly how it differs/overlaps with #2653

Member

snappizz commented Jan 31, 2017

What about #2329? I forgot exactly how it differs/overlaps with #2653

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment