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

[jostM <sc3@xxxxxxxx>]

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/