-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Most examples in 'examples/GUI examples' do not work #560
Comments
since you were looking at it, which examples do not work? |
All of the above contain references to GUI.cocoa and GUI.swing, which should probably be removed. |
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. |
On Wednesday 03 October 2012 09:52:42 scztt wrote:
There will still be usecases for GUI.swing in the future (e.g. running a GUI sincerely, |
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. |
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). |
the question is, if we should support it. talking with sciss during |
On Thursday 04 October 2012 09:55:59 Tim Blechmann wrote:
I think the layout stuff would not be too hard to add to SwingOSC, I think In any case we could keep the old implementations in some way (move to a quark sincerely, |
On 5 Oct 2012, at 09:51, sensestage 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, 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 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. |
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.
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. |
On 5 Oct 2012, at 10:23, Jakob Leben wrote:
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. |
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 |
(can we add the "comp: QT GUI" label to this?) |
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.
The text was updated successfully, but these errors were encountered: