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

Re: [Sc-devel] Knob



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