[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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/