Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

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

Open
scztt opened this Issue · 13 comments

7 participants

@scztt
Owner

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

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
@scztt
Owner

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
Owner

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
@sensestage
@muellmusik
Owner
@jleben
Owner

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
Owner
@jleben
Owner

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

@scztt scztt modified the milestone: 3.7
@scztt scztt added the bug label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.