Thread: [Swingosc-devel] patch for EZ behaviour
Brought to you by:
sciss
Menu
▾
▴
swingosc-devel
|
From: nescivi <ne...@gm...> - 2009-04-12 02:50:48
Attachments:
ezbehaviour.diff
|
Hiho, attached is a diff with all the improvements Alberto made to improve and provide a consistent behaviour of using arrow keys and key modifiers to control sliders, knobs, number boxes, range sliders and so on. ok to commit? this patch will make everything behave the same as in Cocoa. sincerely, Marije |
|
From: Sciss <co...@sc...> - 2009-04-12 16:34:57
|
hi marije,
there is a lot of problems with your diff, mainly because you are
reverting a lot of class files to previous versions and thereby
undoing a lot of recent changes and fixes!
- first, in the build.xml script:
"/usr/share/java/ant-contrib-1.0b3.jar"/
that doesn't look like it will help many people, unless they have
exactly the same version installed... does it do any harm if that jar
file is not there?
- in JSCView.sc you are undoing the fixes to JSCTopView
(absoluteBounds and the fix for relativeOrigin_( false )) :
/**
- * @version 0.61, 11-Apr-09
+ * @version 0.61, 13-Jan-09
* @author Hanns Holger Rutz
*/
JSCContainerView : JSCView { // abstract class
@@ -330,8 +330,6 @@
});
}
- absoluteBounds { ^this.bounds }
-
- prBoundsReadOnly {
- if( scBounds.isNil, {
- // need to revalidate bounds
- scBounds = jinsets.addTo( jBounds );
- });
- ^scBounds;
- }
- same with JSCDragView:
- var <>interpretDroppedStrings = false;
+ var <>interpretDroppedStrings = true;
- ... and JSCTextField
open { arg path;
- var file;
- if( path.beginsWith( "SC://" ), {
- path = Help.findHelpFile( path.copyToEnd( 5 ));
- }, {
- path = path.absolutePath;
+ Platform.case(\windows, {
+ if(path[1]==$:){
+ // Windows path styles "C:\blah" will need an extra slash at start
+ path = "/" ++ path
+ };
+ path = path.tr($\\, $/);
});
- server.sendMsg( '/method', this.id, \setPage, '[', '/methodr',
'[', '/new', "java.io.File", path, ']', 'toURL', ']' );
+ path = path.replace( ' ', '%20' );
+
+ if ( path.contains( "SC://"), {
+ path = Help.findHelpFile( path.asRelativePath( "SC:/") );
+ });
+
+ if ( path.contains( "://" ).not, {
+ if ( path.first.asString != "/" ) { path = String.scDir +/+ path; };
+ path = "file://"++path;
+ });
+ this.openURL( path );
}
your patch will try to revert to old behaviour. this is wrong in all
cases. again: please work with the most recent class files! please
just adjust the increment / scroll etc. methods.
- there is more cases, e.g. JSCEnvelopeView, where you have been
working with an obsolete version. your diff will remove the additions
and fixes to JSCEnvelopeView.
so if you go again from the latest class files and apply the new
scroll / increment methods, i think it's ok + good!
ciao, -sciss-
Am 12.04.2009 um 04:50 schrieb nescivi:
> Hiho,
>
> attached is a diff with all the improvements Alberto made to improve
> and provide a consistent behaviour of using arrow keys and key
> modifiers to control sliders, knobs, number boxes, range sliders and
> so on.
>
> ok to commit?
>
> this patch will make everything behave the same as in Cocoa.
>
> sincerely,
> Marije<ezbehaviour.diff>----------------------------------------------
> --------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-
> com_______________________________________________
> Swingosc-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swingosc-devel
|
|
From: nescivi <ne...@gm...> - 2009-04-12 17:42:57
|
Hiho,
On 4/12/09, Sciss <co...@sc...> wrote:
> hi marije,
>
> there is a lot of problems with your diff, mainly because you are
> reverting a lot of class files to previous versions and thereby
> undoing a lot of recent changes and fixes!
>
> - first, in the build.xml script:
>
> "/usr/share/java/ant-contrib-1.0b3.jar"/
>
> that doesn't look like it will help many people, unless they have
> exactly the same version installed... does it do any harm if that jar
> file is not there?
Ok, this one should not be part of the diff.
I need this fix to get it to build on my system, but I will of course
keep this out of the svn version.
> - in JSCView.sc you are undoing the fixes to JSCTopView
> (absoluteBounds and the fix for relativeOrigin_( false )) :
>
> /**
> - * @version 0.61, 11-Apr-09
> + * @version 0.61, 13-Jan-09
> * @author Hanns Holger Rutz
> */
> JSCContainerView : JSCView { // abstract class
> @@ -330,8 +330,6 @@
> });
> }
>
> - absoluteBounds { ^this.bounds }
>
> -
> - prBoundsReadOnly {
> - if( scBounds.isNil, {
> - // need to revalidate bounds
> - scBounds = jinsets.addTo( jBounds );
> - });
> - ^scBounds;
> - }
>
>
> - same with JSCDragView:
>
> - var <>interpretDroppedStrings = false;
> + var <>interpretDroppedStrings = true;
>
> - ... and JSCTextField
>
> open { arg path;
> - var file;
> - if( path.beginsWith( "SC://" ), {
> - path = Help.findHelpFile( path.copyToEnd( 5 ));
> - }, {
> - path = path.absolutePath;
> + Platform.case(\windows, {
> + if(path[1]==$:){
> + // Windows path styles "C:\blah" will need an extra slash at start
> + path = "/" ++ path
> + };
> + path = path.tr($\\, $/);
> });
> - server.sendMsg( '/method', this.id, \setPage, '[', '/methodr',
> '[', '/new', "java.io.File", path, ']', 'toURL', ']' );
> + path = path.replace( ' ', '%20' );
> +
> + if ( path.contains( "SC://"), {
> + path = Help.findHelpFile( path.asRelativePath( "SC:/") );
> + });
> +
> + if ( path.contains( "://" ).not, {
> + if ( path.first.asString != "/" ) { path = String.scDir +/+ path; };
> + path = "file://"++path;
> + });
> + this.openURL( path );
> }
>
> your patch will try to revert to old behaviour. this is wrong in all
> cases. again: please work with the most recent class files! please
> just adjust the increment / scroll etc. methods.
>
> - there is more cases, e.g. JSCEnvelopeView, where you have been
> working with an obsolete version. your diff will remove the additions
> and fixes to JSCEnvelopeView.
>
> so if you go again from the latest class files and apply the new
> scroll / increment methods, i think it's ok + good!
Ok, AdC did not have the most recent files.
I'll get a proper diff.
sincerely,
Marije
|
|
From: nescivi <ne...@gm...> - 2009-04-15 01:22:41
Attachments:
ezdiff.diff
|
Hiho, how about this diff? sincerely, Marije |
|
From: Sciss <co...@sc...> - 2009-04-15 09:56:55
|
hi marije,
thanks, it looks good.
BUT: i think you are wrong with the new defaultKeyDownAction of
JSCNumberField. you know that JSCTextField and JSCNumberBox are
behaving a lot different than cocoa SCTextFieldOld and SCNumberBox,
in that the key handling is 99% done on the server side. so SClang
should _not_
- change the text colour
- add characters to its string representation (this is done by the
DocumentListener already; you would mess it up when duplicating this
activity)
- react to return and delete keys (this is done on the server)
- react to cursor left and right (as we have a proper cursor/caret in
the gadget unlike old-style SCNumberBox; think of the difference
between SCTextFieldOld and SCTextField!)
- so as far as i see, it boils down instead to:
defaultKeyDownAction { arg char, modifiers, unicode;
- if( unicode == 0xF700, { this.increment; ^this });
- if( unicode == 0xF703, { ^this });
- if( unicode == 0xF701, { this.decrement; ^this });
- if( unicode == 0xF702, { ^this });
- if( (char == $\r) || (char == $\n), { ^this }); // enter key
- if( char.isDecDigit or: { "+-.eE".includes( char )}, { ^this });
- ^nil; // bubble if it's an invalid key
So changing the text colour is IMO a bad idea, and also unnecessary
as you have a proper cursor and the look-and-feel takes care of how
the stuff looks, including text colours etc.
secondly, i think you might create a race condition here, as you
check for the return key. note that there are two event handlers
registerd: a KeyListener and a NumberListener. the NumberListener
gets notified about editing commits such as hitting return, and the
corresponding OSC responder on the SClang side will take care of
calling valueAction. At the same time KeyListener receives
notification from the return hit, and eventually your new code in
defaultKeyDownAction will be called. I guess the result is that
valueAction is called twice.
i don't have time in this moment to verify this observation, but i
ask you to make sure there is no conflict with the new
defaultKeyDownAction. also the checking against digits worries me. i
am 99% sure this code is all wrong and needs to be removed:
defaultKeyDownAction { arg char, modifiers, unicode;
+ var zoom = this.getScale(modifiers);
- if( unicode == 0xF700, { this.increment; ^this });
+ if (unicode == 0xF700, { this.increment(zoom); ^this });
- if( unicode == 0xF701, { this.decrement; ^this });
+ if (unicode == 0xF701, { this.decrement(zoom); ^this });
please try this version (i don't have time in this moment to apply +
check the diff). you need to be very carefully with copy+pasting code
from the cocoa widgets, the internals are often not the same!
thanks anyway + go ahead with the commits after checking the
JSCNumberBox issue.
ciao, -sciss-
Am 15.04.2009 um 03:22 schrieb nescivi:
> Hiho,
>
> how about this diff?
>
> sincerely,
> Marije<ezdiff.diff>---------------------------------------------------
> ---------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-
> com_______________________________________________
> Swingosc-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swingosc-devel
|
|
From: Sciss <co...@sc...> - 2009-04-15 10:05:55
|
i'm sorry there was some extra text in the mail that was supposed to
be removed.... so again my message ;-)
hi marije,
thanks, it looks good.
BUT: i think you are wrong with the new defaultKeyDownAction of
JSCNumberField. you know that JSCTextField and JSCNumberBox are
behaving a lot different than cocoa SCTextFieldOld and SCNumberBox,
in that the key handling is 99% done on the server side. so SClang
should _not_
- change the text colour
- add characters to its string representation (this is done by the
DocumentListener already; you would mess it up when duplicating this
activity)
- react to return and delete keys (this is done on the server)
- react to cursor left and right (as we have a proper cursor/caret in
the gadget unlike old-style SCNumberBox; think of the difference
between SCTextFieldOld and SCTextField!)
- so as far as i see, it boils down instead to:
defaultKeyDownAction { arg char, modifiers, unicode;
+ var zoom = this.getScale(modifiers);
- if( unicode == 0xF700, { this.increment; ^this });
+ if (unicode == 0xF700, { this.increment(zoom); ^this });
- if( unicode == 0xF701, { this.decrement; ^this });
+ if (unicode == 0xF701, { this.decrement(zoom); ^this });
please try this version (i don't have time in this moment to apply +
check the diff). you need to be very carefully with copy+pasting code
from the cocoa widgets, the internals are often not the same!
thanks anyway + go ahead with the commits after checking the
JSCNumberBox issue.
ciao, -sciss-
Am 15.04.2009 um 11:56 schrieb Sciss:
> hi marije,
>
> thanks, it looks good.
>
> BUT: i think you are wrong with the new defaultKeyDownAction of
> JSCNumberField. you know that JSCTextField and JSCNumberBox are
> behaving a lot different than cocoa SCTextFieldOld and SCNumberBox,
> in that the key handling is 99% done on the server side. so SClang
> should _not_
>
> - change the text colour
> - add characters to its string representation (this is done by the
> DocumentListener already; you would mess it up when duplicating this
> activity)
> - react to return and delete keys (this is done on the server)
> - react to cursor left and right (as we have a proper cursor/caret in
> the gadget unlike old-style SCNumberBox; think of the difference
> between SCTextFieldOld and SCTextField!)
> - so as far as i see, it boils down instead to:
>
> defaultKeyDownAction { arg char, modifiers, unicode;
> - if( unicode == 0xF700, { this.increment; ^this });
> - if( unicode == 0xF703, { ^this });
> - if( unicode == 0xF701, { this.decrement; ^this });
> - if( unicode == 0xF702, { ^this });
> - if( (char == $\r) || (char == $\n), { ^this }); // enter key
> - if( char.isDecDigit or: { "+-.eE".includes( char )}, { ^this });
> - ^nil; // bubble if it's an invalid key
>
>
> So changing the text colour is IMO a bad idea, and also unnecessary
> as you have a proper cursor and the look-and-feel takes care of how
> the stuff looks, including text colours etc.
>
>
> secondly, i think you might create a race condition here, as you
> check for the return key. note that there are two event handlers
> registerd: a KeyListener and a NumberListener. the NumberListener
> gets notified about editing commits such as hitting return, and the
> corresponding OSC responder on the SClang side will take care of
> calling valueAction. At the same time KeyListener receives
> notification from the return hit, and eventually your new code in
> defaultKeyDownAction will be called. I guess the result is that
> valueAction is called twice.
>
> i don't have time in this moment to verify this observation, but i
> ask you to make sure there is no conflict with the new
> defaultKeyDownAction. also the checking against digits worries me. i
> am 99% sure this code is all wrong and needs to be removed:
>
> defaultKeyDownAction { arg char, modifiers, unicode;
> + var zoom = this.getScale(modifiers);
> - if( unicode == 0xF700, { this.increment; ^this });
> + if (unicode == 0xF700, { this.increment(zoom); ^this });
> - if( unicode == 0xF701, { this.decrement; ^this });
> + if (unicode == 0xF701, { this.decrement(zoom); ^this });
>
> please try this version (i don't have time in this moment to apply +
> check the diff). you need to be very carefully with copy+pasting code
> from the cocoa widgets, the internals are often not the same!
>
> thanks anyway + go ahead with the commits after checking the
> JSCNumberBox issue.
>
> ciao, -sciss-
>
|
|
From: nescivi <ne...@gm...> - 2009-04-21 02:03:57
|
Hiho,
On Wednesday 15 April 2009 06:05:47 Sciss wrote:
> i'm sorry there was some extra text in the mail that was supposed to
> be removed.... so again my message ;-)
>
> hi marije,
>
> thanks, it looks good.
>
> BUT: i think you are wrong with the new defaultKeyDownAction of
> JSCNumberField. you know that JSCTextField and JSCNumberBox are
> behaving a lot different than cocoa SCTextFieldOld and SCNumberBox,
> in that the key handling is 99% done on the server side. so SClang
> should _not_
I don't know :)
I try to avoid having to use mac's, so I am not totally familiar with the
cocoa gui widget behaviours.
> - change the text colour
> - add characters to its string representation (this is done by the
> DocumentListener already; you would mess it up when duplicating this
> activity)
> - react to return and delete keys (this is done on the server)
> - react to cursor left and right (as we have a proper cursor/caret in
> the gadget unlike old-style SCNumberBox; think of the difference
> between SCTextFieldOld and SCTextField!)
> - so as far as i see, it boils down instead to:
> defaultKeyDownAction { arg char, modifiers, unicode;
> + var zoom = this.getScale(modifiers);
> - if( unicode == 0xF700, { this.increment; ^this });
> + if (unicode == 0xF700, { this.increment(zoom); ^this });
> - if( unicode == 0xF701, { this.decrement; ^this });
> + if (unicode == 0xF701, { this.decrement(zoom); ^this });
Ok, so that's only for the JSCNumberBox?
> please try this version (i don't have time in this moment to apply +
> check the diff). you need to be very carefully with copy+pasting code
> from the cocoa widgets, the internals are often not the same!
In this case I'm just the messenger :)
> thanks anyway + go ahead with the commits after checking the
> JSCNumberBox issue.
sincerely,
Marije
> ciao, -sciss-
>
> Am 15.04.2009 um 11:56 schrieb Sciss:
> > hi marije,
> >
> > thanks, it looks good.
> >
> > BUT: i think you are wrong with the new defaultKeyDownAction of
> > JSCNumberField. you know that JSCTextField and JSCNumberBox are
> > behaving a lot different than cocoa SCTextFieldOld and SCNumberBox,
> > in that the key handling is 99% done on the server side. so SClang
> > should _not_
> >
> > - change the text colour
> > - add characters to its string representation (this is done by the
> > DocumentListener already; you would mess it up when duplicating this
> > activity)
> > - react to return and delete keys (this is done on the server)
> > - react to cursor left and right (as we have a proper cursor/caret in
> > the gadget unlike old-style SCNumberBox; think of the difference
> > between SCTextFieldOld and SCTextField!)
> > - so as far as i see, it boils down instead to:
> >
> > defaultKeyDownAction { arg char, modifiers, unicode;
> > - if( unicode == 0xF700, { this.increment; ^this });
> > - if( unicode == 0xF703, { ^this });
> > - if( unicode == 0xF701, { this.decrement; ^this });
> > - if( unicode == 0xF702, { ^this });
> > - if( (char == $\r) || (char == $\n), { ^this }); // enter key
> > - if( char.isDecDigit or: { "+-.eE".includes( char )}, { ^this });
> > - ^nil; // bubble if it's an invalid key
> >
> >
> > So changing the text colour is IMO a bad idea, and also unnecessary
> > as you have a proper cursor and the look-and-feel takes care of how
> > the stuff looks, including text colours etc.
> >
> >
> > secondly, i think you might create a race condition here, as you
> > check for the return key. note that there are two event handlers
> > registerd: a KeyListener and a NumberListener. the NumberListener
> > gets notified about editing commits such as hitting return, and the
> > corresponding OSC responder on the SClang side will take care of
> > calling valueAction. At the same time KeyListener receives
> > notification from the return hit, and eventually your new code in
> > defaultKeyDownAction will be called. I guess the result is that
> > valueAction is called twice.
> >
> > i don't have time in this moment to verify this observation, but i
> > ask you to make sure there is no conflict with the new
> > defaultKeyDownAction. also the checking against digits worries me. i
> > am 99% sure this code is all wrong and needs to be removed:
> >
> > defaultKeyDownAction { arg char, modifiers, unicode;
> > + var zoom = this.getScale(modifiers);
> > - if( unicode == 0xF700, { this.increment; ^this });
> > + if (unicode == 0xF700, { this.increment(zoom); ^this });
> > - if( unicode == 0xF701, { this.decrement; ^this });
> > + if (unicode == 0xF701, { this.decrement(zoom); ^this });
> >
> > please try this version (i don't have time in this moment to apply +
> > check the diff). you need to be very carefully with copy+pasting code
> > from the cocoa widgets, the internals are often not the same!
> >
> > thanks anyway + go ahead with the commits after checking the
> > JSCNumberBox issue.
> >
> > ciao, -sciss-
|
|
From: nescivi <ne...@gm...> - 2009-04-15 15:57:28
|
Hiho,
just CC'ing Alberto in this, since he really made the patch and not me.
sincerely,
Marije
On Wednesday 15 April 2009 06:05:47 Sciss wrote:
> i'm sorry there was some extra text in the mail that was supposed to
> be removed.... so again my message ;-)
>
> hi marije,
>
> thanks, it looks good.
>
> BUT: i think you are wrong with the new defaultKeyDownAction of
> JSCNumberField. you know that JSCTextField and JSCNumberBox are
> behaving a lot different than cocoa SCTextFieldOld and SCNumberBox,
> in that the key handling is 99% done on the server side. so SClang
> should _not_
>
> - change the text colour
> - add characters to its string representation (this is done by the
> DocumentListener already; you would mess it up when duplicating this
> activity)
> - react to return and delete keys (this is done on the server)
> - react to cursor left and right (as we have a proper cursor/caret in
> the gadget unlike old-style SCNumberBox; think of the difference
> between SCTextFieldOld and SCTextField!)
> - so as far as i see, it boils down instead to:
>
> defaultKeyDownAction { arg char, modifiers, unicode;
> + var zoom = this.getScale(modifiers);
> - if( unicode == 0xF700, { this.increment; ^this });
> + if (unicode == 0xF700, { this.increment(zoom); ^this });
> - if( unicode == 0xF701, { this.decrement; ^this });
> + if (unicode == 0xF701, { this.decrement(zoom); ^this });
>
> please try this version (i don't have time in this moment to apply +
> check the diff). you need to be very carefully with copy+pasting code
> from the cocoa widgets, the internals are often not the same!
>
> thanks anyway + go ahead with the commits after checking the
> JSCNumberBox issue.
>
> ciao, -sciss-
>
> Am 15.04.2009 um 11:56 schrieb Sciss:
> > hi marije,
> >
> > thanks, it looks good.
> >
> > BUT: i think you are wrong with the new defaultKeyDownAction of
> > JSCNumberField. you know that JSCTextField and JSCNumberBox are
> > behaving a lot different than cocoa SCTextFieldOld and SCNumberBox,
> > in that the key handling is 99% done on the server side. so SClang
> > should _not_
> >
> > - change the text colour
> > - add characters to its string representation (this is done by the
> > DocumentListener already; you would mess it up when duplicating this
> > activity)
> > - react to return and delete keys (this is done on the server)
> > - react to cursor left and right (as we have a proper cursor/caret in
> > the gadget unlike old-style SCNumberBox; think of the difference
> > between SCTextFieldOld and SCTextField!)
> > - so as far as i see, it boils down instead to:
> >
> > defaultKeyDownAction { arg char, modifiers, unicode;
> > - if( unicode == 0xF700, { this.increment; ^this });
> > - if( unicode == 0xF703, { ^this });
> > - if( unicode == 0xF701, { this.decrement; ^this });
> > - if( unicode == 0xF702, { ^this });
> > - if( (char == $\r) || (char == $\n), { ^this }); // enter key
> > - if( char.isDecDigit or: { "+-.eE".includes( char )}, { ^this });
> > - ^nil; // bubble if it's an invalid key
> >
> >
> > So changing the text colour is IMO a bad idea, and also unnecessary
> > as you have a proper cursor and the look-and-feel takes care of how
> > the stuff looks, including text colours etc.
> >
> >
> > secondly, i think you might create a race condition here, as you
> > check for the return key. note that there are two event handlers
> > registerd: a KeyListener and a NumberListener. the NumberListener
> > gets notified about editing commits such as hitting return, and the
> > corresponding OSC responder on the SClang side will take care of
> > calling valueAction. At the same time KeyListener receives
> > notification from the return hit, and eventually your new code in
> > defaultKeyDownAction will be called. I guess the result is that
> > valueAction is called twice.
> >
> > i don't have time in this moment to verify this observation, but i
> > ask you to make sure there is no conflict with the new
> > defaultKeyDownAction. also the checking against digits worries me. i
> > am 99% sure this code is all wrong and needs to be removed:
> >
> > defaultKeyDownAction { arg char, modifiers, unicode;
> > + var zoom = this.getScale(modifiers);
> > - if( unicode == 0xF700, { this.increment; ^this });
> > + if (unicode == 0xF700, { this.increment(zoom); ^this });
> > - if( unicode == 0xF701, { this.decrement; ^this });
> > + if (unicode == 0xF701, { this.decrement(zoom); ^this });
> >
> > please try this version (i don't have time in this moment to apply +
> > check the diff). you need to be very carefully with copy+pasting code
> > from the cocoa widgets, the internals are often not the same!
> >
> > thanks anyway + go ahead with the commits after checking the
> > JSCNumberBox issue.
> >
> > ciao, -sciss-
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X