Hi all.
Interesting discussion. Here are my 2cents on the GUI issue:
We spent the last weekend on porting ixiQuarks to SwingOSC.
I can tell you it was no fun. When working with complex GUIs and GUI
updates,
an OSC GUI server is not as desirable as a GUI toolkit inbuilt with
the language.
And on our machines (Powerbook 1000 Hz and IBM 1500 Hz (I think)) Java
was quite slow and did not give the feeling of a solid, well
functioning software.
(There were lots of things that were not translatable from Cocoa to
SwingOSC.
I can provide a list if anyone is interested.)
I think Qt is a much more appropriate choice. It's free as long as it
is GPL and
properly cross platform.
There is also Juce:
http://www.rawmaterialsoftware.com/juce/(looks like cycling coded Max5 with it???)
So my view is this:
a) ideally the GUI should be part of the language (and not a GUI OSC
server)
b) It should not be Java or any other slow language.
I would hope that in future versions of SC, the GUI could draw real-
time time domain
and frequency domain views and that is not easy to do when passing
OSC data around like we're doing now. (Spectral view is not really
possible
although Scott made a cool implementation in QC. And the wave view
(scope)
is much worse than it was in SC2).
This is hard to implement in SC3 (Unless someone really makes an
effort to
incorporate Qt with the sourcecode - not as a server).
Perhaps SC4 will give us a good solution for GUIs?
thor
PS. the above is not meant to devalue in any way Sciss's SwingOSC server
which is fantastic temporary solution and very good work indeed.
(where would we be without it???)
On 2 May 2008, at 10:43, Dan Stowell wrote:
> 2008/5/2 James Harkins <
jamshark70@...>:
>>
>> On Apr 30, 2008, at 5:13 AM, John Glover wrote:
>>
>>> Personally I think it would be a good idea to create a sclang app on
>>> windows so things are closer to the other platforms. The GUI app
>>> could
>>> then be written in something cross-platform such as QT, WxWidgets or
>>> even Java.
>>
>> I remember we had this discussion once upon a time, but nobody
>> could agree
>> which toolkit to use. While the fur was flying, sciss got started on
>> swingosc and ended up doing such a fantastic job on it that it
>> basically
>> stopped the conversation.
>>
>> I don't have any strong objection to reimplementing the cocoa
>> widgets using
>> some other toolkit, provided the sc classes retain as much
>> compatibility as
>> possible with existing user code.
>
> I agree that if the "main" or "default" sclang editor was a
> cross-platform one that would be great, and would be a good way to
> make the best use of limited developer time. I can see that trying to
> get community agreement on a toolkit (or whatever) would be futile -
> would we have agreed on a Java GUI server? I doubt it, instead sciss
> just made it and It Was Good.
>
> Similarly the future of crossplatform sclang editor is going to be
> determined by where the developer effort goes and where the
> user-takeup goes. At the moment we have plenty of interesting
> candidates, and I feel like the evolutionary race is just beginning...
>
> Dan
> _______________________________________________
> sc-users mailing list
>
sc-users@...
>
http://lists.create.ucsb.edu/mailman/listinfo/sc-users_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users