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

Re: [Sc-devel] Knob



Aside from the points I mentioned, I have to agree with you that it'd
be best to have a single object working perfect in both kits.

I am a bit pressed for time now and I might not be able to really look
at this until mids next week.

It occurred to me now that maybe the best way is to create an abstract
class, a wrapper to SCUserView, one that emulates 100% GUI.view and
inherit from there. This might also serve for other objects that are
planed to work on different kits besides cocoa.

cheers,

x



On Feb 4, 2008 4:02 AM, Sciss <contact@xxxxxxxx> wrote:
> well i thought that if there would be only Knob (that automatically
> adapts to GUI), it would make sense to remove GUI.knob and references
> to it, so people would be advised to use Knob directly. But i
> understand your point that a user-view based thing might be
> temporary. So yes, maybe i should do the JKnob registration. Since i
> don't do it right now in the current version, i would ask you to
> leave the registration code in Knob, and i will tell you once i have
> the code in a SwingOSC update, so the duplicate code could be removed
> from Knob:*initClass...
>
> ciao, -sciss-
>
>
> Am 04.02.2008 um 10:58 schrieb blackrain:
>
>
> > About the class initializer, we could remove it from Knob and allow
> > JKnob to map itself when present. I think that makes more sense? or
> > did you have something in mind?
> >
> > cheers,
> >
> > x
> >
> > On Feb 4, 2008 3:41 AM, Sciss <contact@xxxxxxxx> wrote:
> >> ah didn't check against EZKnob, KnobEditor etc. well no problem, i
> >> keep JKnob for the time being...
> >>
> >> cheers, -sciss-
> >>
> >>
> >> Am 04.02.2008 um 08:30 schrieb blackrain:
> >>
> >>
> >>> Hi Sciss,
> >>> Thanks for your work on this =)
> >>>
> >>> I just tested your code and yes, EZKnob and the CX Knob editors are
> >>> broken plus the issues you mention.
> >>>
> >>> Back in the days when the GUI kits approach was being plotted, there
> >>> was a discussion about Knob, JKnob and SCKnob. The point in bringing
> >>> that now is that SwingOSC will need a JKnob implementation the
> >>> day it
> >>> comes for us to have a SCKnob primitive - which you already have
> >>> working with JKnob.
> >>> I see Knob as a temporary 'helper' object in the absence of a true
> >>> Cocoa primitive.
> >>>
> >>> Excuse me if I am missing a cue point so let me know what you think.
> >>>
> >>> regards,
> >>>
> >>> x
> >>>
> >>> On Feb 3, 2008 10:45 AM, Sciss <contact@xxxxxxxx> wrote:
> >>>> hi blackrain (again),
> >>>>
> >>>> what do you think? i have made a Knob version that should work both
> >>>> with CocoaGUI and SwingGUI. if that's fine with you, i will remove
> >>>> JKnob from SwingOSC. the only issue is the jumping of the knob in
> >>>> \vert and \horiz mode when starting a drag because mousePosition
> >>>> reports a wrong value on cocoa (see other mail earlier), but i
> >>>> guess
> >>>> that's gonna be fixed. Also i don't know about the *viewClass
> >>>> method
> >>>> and whether the view still works properly in crucial GUI(?)
> >>>> contexts.
> >>>>
> >>>> ciao, -sciss-
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Am 03.02.2008 um 15:58 schrieb Sciss:
> >>>>
> >>>>> hi blackrain,
> >>>>>
> >>>>> i was wondering if i remove JKnob from SwingOSC, basically your
> >>>>> Knob
> >>>>> should work with both kits if you remove the need to subclass
> >>>>> SCUserView and replace Pen by GUI.pen. Anyway, the static
> >>>>> initializer
> >>>>> is weird:
> >>>>>
> >>>>>       *initClass {
> >>>>>               defaultMode='round'; // early so this can be
> >>>>> changed in startup
> >>>>>               StartUp.add({ var kit;
> >>>>>                       kit = GUI.schemes[ \cocoa ];
> >>>>>                       if( kit.notNil, { kit.knob = Knob });
> >>>>>                       kit = GUI.schemes[ \swing ];
> >>>>>                       if( kit.notNil, { kit.knob = JKnob });
> >>>>>               });
> >>>>>       }
> >>>>>
> >>>>>
> >>>>> i mean, you register JKnob even though it's not part of the Knob
> >>>>> quark... i think this should be changed maybe. i'll give it a try
> >>>>> and
> >>>>> we can see if it makes sense...
> >>>>>
> >>>>> ciao, -sciss-
> >>>>>
> >>>>> _______________________________________________
> >>>>> Sc-devel mailing list
> >>>>> Sc-devel@xxxxxxxxxxxxxxx
> >>>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Sc-devel mailing list
> >>>> Sc-devel@xxxxxxxxxxxxxxx
> >>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Sc-devel mailing list
> >>> Sc-devel@xxxxxxxxxxxxxxx
> >>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >>
> >> _______________________________________________
> >> Sc-devel mailing list
> >> Sc-devel@xxxxxxxxxxxxxxx
> >> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >>
> > _______________________________________________
> > Sc-devel mailing list
> > Sc-devel@xxxxxxxxxxxxxxx
> > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>