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

[scztt]

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]

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

[scztt]

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

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]

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]

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]

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]

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

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]

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]

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]

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]

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

[vivid-synth]

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

[nhthn]

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