[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Getting back to ViewRedirect from a View
Hi Ron,
I can add onClose to EZGui, though it really would simply return/set
view.onClose. view is always the CompositeView container.
Concerning the gui stuff: it is probably not feasible, nor even
desirable, to be able to subclass Slider, and have that apply to all
redirects of Slider. And I also think people will wan to be able to mix
GUI schemes if necessary. I am beginning to think that we need a way to
manage class overrides and additions, if the superclass is not
available. Then you could subclass both SCSlider and JSCSlider, but
there would be no trouble if SwingOSC is not installed.
Perhaps this could be part of the quarks mechanism( only include
JSCSLiderPlus.sc,or only include thinds in a SwingOSC directory, if
SwingOSC is loaded). This is probably the least difficult alternative.
It would be more involved if the compiler could make such distinctions.
best,
Jost
ronald kuivila wrote:
> Hi Jost,
>
> The workaround for me is to do everything in the GUIEvent.
> But the subclassing problem is real and inescapable. I don't really see a
> way around it without a substantial redesign. (Seems like there would
> need to be a way to
> have a single class library that interfaces to both sets of graphics
> primitives.)
>
> RJK
>
>
> BTW: could we add onClose to the EZ classes?
>
>
> On Dec 31, 2008, at 4:14 AM, jostM wrote:
>
>> 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/
>>
>
>
> _______________________________________________
> 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/