Re: [sc-dev] Getting back to ViewRedirect from a View

[jostM <sc3@xxxxxxxx>]

let me know what you did. Subclassing gui classes is turning out to be a
problem (even with the GUI.myWidget technique)

jost

ronald kuivila wrote:
> Hi Jost,
>
> Actually, I may be able to handle this a little differently.
> So, let's hold off for the moment.
>
> RJK
>
>
> On Dec 30, 2008, at 6:42 PM, jostM wrote:
>
>> ok, now I see the problem.
>>
>> we could put this in SCView:
>>
>> +SCView{
>>    genericName {
>>    var classKey;
>>
>>    classKey=this.class.asString;
>>    classKey[0]=classKey[0].toLower;
>>
>>   ^classKey.asSymbol
>>
>> }
>>
>>
>>
>> and then it could be overridden in those classes where the key is not
>> like that (SC2DSlider is slider2d, e.g.).
>>
>> that would make less clutter.
>>
>> (did you need this as a class method?)
>>
>>
>> I think the idea with the dictionary is too awkward. People have to be
>> able to subclass without too much hassle. I guess someone will have to
>> write a little cross platform subclassing tutorial. We could use your
>> technique and add it to the SCUserView subclassing tutorial I wrote.
>>
>>
>> any other suggestions?
>>
>>
>> Jost
>>
>> ronald kuivila wrote:
>>>
>>> Hi Jost and all,
>>>
>>> To make CV work for both Swing and Cocoa, it has to work whether or
>>> not the library is installed. So, I cannot
>>> subclass directly, but I still have to attach an action to the actual
>>> view.  (Since the interfaces are identical this is not that big a
>>> deal.)
>>>
>>> The easiest way to do this would be to have a method for every view
>>> (cocoa or swing) that provides its  ViewRedirect classname.
>>> This could be something like:
>>>
>>> +SCSlider {
>>>    genericName { ^'slider' }
>>> }
>>>
>>>  This seems plausible, but I don't know if there is enough need to
>>> clutter up all the view classes.
>>>
>>> Alternatively, I can just generate a Dictionary in StartUp (by
>>> reading the schemes available to GUI and looking everything up)
>>> and keep it inside CV.
>>>
>>> Any thoughts, preferences or alternative approaches?
>>>
>>>
>>> RJK
>>>
>>>
>>>
>>>
>>>
>>> On Dec 30, 2008, at 11:31 AM, Jost Muxfeldt wrote:
>>>> I wasn't quite sure what you were asking me, but: the only reason I
>>>> used
>>>> ViewRedirect for EZSlider was that relativeOrigin is not
>>>> implemented yet
>>>> for swing containters. EZSlider is written for cross platform, it's
>>>> just
>>>> that I have to redirect to the old version for swing at the moment.
>>>> The
>>>> old version is EZSliderJ for swing, and the new one is EZSliderSC for
>>>> Cocoa.  Once relativeOrigin is implemented for swing, there will
>>>> only be
>>>> EZSlider, namely the new one.
>>>>
>>>> You were subclassing EZSlider, so you have to substitute that for
>>>> EZSliderSC temporarily (I really hope sciss gets this done before 3.3,
>>>> it would really make things easier). If you want to be cross platform,
>>>> duplicate your extra methods and subclass both EZSliderSC and
>>>> EZSliderJ.
>>>> In the actual code, you will the redirect class, EZSlider.
>>>>
>>>> as for where to find other schemes, there is only on other one, an
>>>> that
>>>> is in the swingOSC library. If you install swingOSC, then you can
>>>> get it
>>>> under SwingGUI.
>>>>
>>>> I hope that was what you wanted to know,
>>>>
>>>> best
>>>>
>>>> Jost
>>>>
>>>>
>>>> ronald kuivila wrote:
>>>>> Hi Jost,
>>>>>
>>>>> I am going to rewrite the CV connect code so that it is all a method
>>>>> of CV and looks up the appropriate connect action.
>>>>> Where do I find the equivalents of CocoaGUI for other GUI schemes?
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.):
>>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
>>> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.):
>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
>> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
>

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/