Re: sc crossplatform future (was re: sc3 with emacs on windows?)

> hi
>
> two more cents on this...
>
> i am probably not the best to talk about this because i dont work so
> much with sclang but maybe my point of view could be interesting  
> for the
> community?.
>
> I work with several tools including PD and Python. I always try to
> develop crossplatform code as much as possible,. So I value languages,
> GUI toolkits and also IDEs which are crosplatform and consistent.
>
> My relation with supercollider is very problematic because I have  
> to use
> use three different IDEs, one for in each platform (gEdit,
> supercollider, psycollider),. Each of them has its own  
> peculiarities and
> small issues. Same goes for GUI, even SwingOSC, which is quite  
> amazing,
> is still buggy.
>
> All this is of course because being supercollider native from OSX most
> users are on OSX and therefore the usage and development of  
> SwingOSC is
> not as intense as we all would dream. Having one single GUI  
> solution for
> all platforms would boost and easy enormously the development of more
> complex GUIs in supercollider.
>
> I know by first hand that developing crossplatform code is a pain  
> in the
> ass but in my opinion it is worth. If we compare the experience of  
> using
> for example PD to that of using supercollider in different platforms
> there is yet a huge gap to fill despite of latest versions  
> advances. PD
> is almost 100% consistent. (I am not trying to say this is better than
> that, just pointing that PD works almost the same in Linux/Win/OSX)
>
> In my opinion a crossplatform and stable GUI and IDE would help
> spreading the usage of supercollider.
>
> enrike
>
> thor(e)k dio:
>> 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
>>
>
> _______________________________________________
> sc-users mailing list
> sc-users@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-users