swingosc-devel — List for Developers of SwingOSC

Re: [Swingosc-devel] Linux LAF

[James H. <jam...@gm...>]

On Mon, Feb 15, 2010 at 12:05 PM, James Harkins <jam...@gm...>wrote:

>
> Small static text views, not so good - even the Volume control in the
> server window is unreadable. I can live with it for now. Or maybe I just
> need more fonts.
>

Oops, no, static text is fine. TextFields/NumberBoxes have a large inner
frame in nimbus, which obscures the content. So I may need to keep looking
for another LAF...

hjh


-- 
James Harkins /// dewdrop world
jam...@de...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

Re: [Swingosc-devel] Linux LAF

[James H. <jam...@gm...>]

On Mon, Feb 15, 2010 at 8:27 AM, Sciss <co...@sc...> wrote:

> if you can install sun's java 1.6, i recommend nimbus which is really great
> looking. if you can't for some reason (e.g. i'm not sure it's included in
> openJDK), you could i think still install it separately from
> https://nimbus.dev.java.net/   . did you try the Gtk look and feel?
>

GTK looks about the same as Motif, only brighter. Here's the problem with
those:

(
w = Window("lo-res slider", Rect(10, 100, 125, 50));
z = Slider(w, Rect(5, 5, 50, 20)).action_({ |view| view.value.postln });
w.front;
)

With GTK/Motif, moving the thumb by 1 pixel changes the value by
0.083333333022892, or 1/12. Very poor resolution.


> nimbus ideally could render differently big slider knobs, but at least in
> the java 1.6 version that snow leopard ships with, the resize hints
> (JComponent.sizeVariant) are broken unfortunately.
>

Thanks for the suggestion. Sliders are much prettier. I have a LOT of them
in my GUI and when they look bad, the whole thing is an assault on the eye.

Small static text views, not so good - even the Volume control in the server
window is unreadable. I can live with it for now. Or maybe I just need more
fonts.

unfortunately i don't have much time, but we could still plan to use a
> custom slider instead of JSlider, as that would allow for more closer
> matching with cocoa gui, e.g. slider track and knob colours etc. the
> original JSlider (which i like quite much) could then be with another
> swingOSC only class.
>

Nah, I don't that's necessary.
hjh


-- 
James Harkins /// dewdrop world
jam...@de...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

Re: [Swingosc-devel] Linux LAF

[Sciss <co...@sc...>]

if you can install sun's java 1.6, i recommend nimbus which is really great looking. if you can't for some reason (e.g. i'm not sure it's included in openJDK), you could i think still install it separately from  https://nimbus.dev.java.net/   . did you try the Gtk look and feel?

nimbus ideally could render differently big slider knobs, but at least in the java 1.6 version that snow leopard ships with, the resize hints (JComponent.sizeVariant) are broken unfortunately.

unfortunately i don't have much time, but we could still plan to use a custom slider instead of JSlider, as that would allow for more closer matching with cocoa gui, e.g. slider track and knob colours etc. the original JSlider (which i like quite much) could then be with another swingOSC only class.

ciao, -sciss.-


Am 15.02.2010 um 02:20 schrieb James Harkins:

> Could anyone suggest a LAF that does not have the fugly sliders that Metal has?
> 
> I tried Motif but the slider thumbs are too wide, cutting down on slider resolution.
> 
> (I'd rather avoid quaqua since I don't care for the blue-candy sliders either.)
> 
> I searched google images but a lot of LAF screenshots don't show sliders, so I have no idea what I'm getting.
> 
> Thanks!
> hjh
> 
> 
> -- 
> James Harkins /// dewdrop world
> jam...@de...
> http://www.dewdrop-world.net
> 
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev_______________________________________________
> Swingosc-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swingosc-devel

Re: [Swingosc-devel] JSCScrollView issue adjusting canvas size to contents

[Sciss <co...@sc...>]

the difference might be in the underlying look-and-feel...
- you could try to use metal or nimbus look and feel on both platforms, if they still behave differently i would suspect a bug in either library.
- other possibility is a race condition somehow that due to different micro timing on linux exhibits different behaviour than on mac. without a reproducable example on mac i can do little about it unfortunately. but since you have a workaround, maybe it's fine?
- last thing would be to look carefully at the OSC dump of both platforms and try to spot any different calls to the scroll view. needless to say that with a complex gui (as you say you have) this will be quite tedious.....

best, -sciss-


Am 15.02.2010 um 02:43 schrieb James Harkins:

> On Sun, Feb 14, 2010 at 9:18 PM, James Harkins <jam...@gm...> wrote:
> In SwingOSC 0.64 (puredyne linux), the scrollview does NOT adjust the inner bounds. There are 1600 pixels of content, but the scrollbar covers 20000 pixels.
> 
> Not sure if this is a solution, but I just found that if I manually refresh the scrollview, it fixes the scrolling area. So I have a workaround... I still wonder why the behavior is different on different OS's with the same SwingOSC.jar and classfiles.
> 
> hjh 
> 
> 
> -- 
> James Harkins /// dewdrop world
> jam...@de...
> http://www.dewdrop-world.net
> 
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev_______________________________________________
> Swingosc-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swingosc-devel

Re: [Swingosc-devel] JSCScrollView issue adjusting canvas size to contents

[James H. <jam...@gm...>]

On Sun, Feb 14, 2010 at 9:18 PM, James Harkins <jam...@gm...> wrote:

> In SwingOSC 0.64 (puredyne linux), the scrollview does NOT adjust the inner
> bounds. There are 1600 pixels of content, but the scrollbar covers 20000
> pixels.
>

Not sure if this is a solution, but I just found that if I manually refresh
the scrollview, it fixes the scrolling area. So I have a workaround... I
still wonder why the behavior is different on different OS's with the same
SwingOSC.jar and classfiles.

hjh


-- 
James Harkins /// dewdrop world
jam...@de...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

[Swingosc-devel] Linux LAF

[James H. <jam...@gm...>]

Could anyone suggest a LAF that does not have the fugly sliders that Metal
has?

I tried Motif but the slider thumbs are too wide, cutting down on slider
resolution.

(I'd rather avoid quaqua since I don't care for the blue-candy sliders
either.)

I searched google images but a lot of LAF screenshots don't show sliders, so
I have no idea what I'm getting.

Thanks!
hjh


-- 
James Harkins /// dewdrop world
jam...@de...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

[Swingosc-devel] JSCScrollView issue adjusting canvas size to contents

[James H. <jam...@gm...>]

This is a weird one. I can't reproduce it with a simple GUI.

My performance GUI sets up a window with a flowview on the left for a
"toolbar," and the right-hand side has some spaces for voicer or process
controls. The right hand side is a scrollview containing a flowview. I found
the guis in the flowview don't work unless I allocate more vertical space
than needed, then shrink the flowview to contents.

In Cocoa, the size of the scroll bar resizes and scrolling to the bottom of
the scrollbar goes to the bottom of the actual content.

In SwingOSC 0.64 (Mac), the scrollview adjusts its innerBounds automatically
(but only after touching the scrollbar), and scrolling correctly goes to the
bottom of the content, no empty space.

The above two are fine. But...

In SwingOSC 0.64 (puredyne linux), the scrollview does NOT adjust the inner
bounds. There are 1600 pixels of content, but the scrollbar covers 20000
pixels.

To reproduce:

Install ddwChucklib, ddwGUIEnhancements and ddwGUIEnhancementsForSwingOSC
quarks.
Recompile lib.
Run in sc:

BP.loadGui;

I've tried to reproduce it with simpler code, but it works correctly in
other scenarios (including drawing only the right-hand panel in a dedicated
window). I don't know what's different about the more complex window that it
would break, but only in linux.

Or, is there a way I can debug this in linux myself? I'm not familiar with
Java dev/debugging tools, though.


-- 
James Harkins /// dewdrop world
jam...@de...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

[Swingosc-devel] Error with SwingOSC on Debian unstable

[nescivi <ne...@gm...>]

Hiho,

I am just getting this error when trying to boot SwingOSC... (first output)
I'm getting a similar error trying to open a socket with Processing (second 
output)...

Any idea what could be the problem?

sincerely,
Marije

$ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)


booting /usr/lib/jvm/java-6-sun/jre/bin/java -
Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -jar 
"/home/nescivi/share/bin/SwingOSC.jar" -t 57131 -L -i -h 127.0.0.1:57120
de.sciss.swingosc.SwingOSC : java.net.SocketException : Invalid argument
	at sun.nio.ch.Net.bind(Native Method)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
	...


Exception in thread "Thread-3" java.lang.Error: Unable to launch target VM: 
java.net.SocketException: Invalid argument
        at processing.app.debug.Runner.launchVirtualMachine(Runner.java:306)
        at processing.app.debug.Runner.launch(Runner.java:117)
        at processing.app.Editor$DefaultRunHandler.run(Editor.java:1634)
        at java.lang.Thread.run(Thread.java:619)

[Swingosc-devel] Bug 1897378

[Sciss <co...@sc...>]

hi,

i wonder if this bug entry is still valid:

https://sourceforge.net/tracker/? 
func=detail&aid=1897378&group_id=155586&atid=796400

"ran through my examples again with psycollider and the only issue i  
now had
was the trail/background thing reported earlier. but fixing this can  
wait.
here's an example. on xp it just flickers. on mac cocoa/swing it adds a
smooth trail to the oval.

(
s.waitForBoot{
var width= 640, height= 480;
var w= GUI.window.new("trails test", Rect(99, 99, width, height),  
false);
var u= GUI.userView.new(w, Rect(0, 0, width, height));
var cnt= 0;
u.drawFunc= {
GUI.pen.fillColor= Color.grey(0, 0.05);
GUI.pen.fillRect(u.bounds);	//manually clear with alpha
GUI.pen.fillColor= Color.white;
GUI.pen.fillOval(Rect.aboutPoint(Point(cnt, height*0.5), 40, 20));
cnt= cnt+2%width;
};
u.clearOnRefresh= false;
u.relativeOrigin= true;
w.view.background= Color.black;
w.front;
Routine({while({w.isClosed.not}, {w.refresh;
(1/25).wait})}).play(AppClock);
};
)

"

result looks like attached pic on mac os x.

can someone on windows check this?

thanks, -sciss-

Re: [Swingosc-devel] JSCTextView action func

[James H. <jam...@gm...>]

Never mind... I think I should have been using keyDownAction instead  
('cuz action seems to be basically ignored in Cocoa).

Sorry for the noise.
hjh

On May 16, 2009, at 10:39 PM, James Harkins wrote:

> It is *way* not cross-platform compatible with the Cocoa equivalent.
>
> I think action should behave the same as Cocoa. There could be a  
> verboseAction e.g. for the current JSCTextView action (receiving  
> every user event).


: H. James Harkins
: jam...@de...
: http://www.dewdrop-world.net
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

[Swingosc-devel] JSCTextView action func

[James H. <jam...@gm...>]

It is *way* not cross-platform compatible with the Cocoa equivalent.

I think action should behave the same as Cocoa. There could be a  
verboseAction e.g. for the current JSCTextView action (receiving  
every user event).

hjh


: H. James Harkins
: jam...@de...
: http://www.dewdrop-world.net
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

Re: [Swingosc-devel] strange problems with swingosc

[Sciss <co...@sc...>]

if the problem is still there, maybe post to sc-users to see if more  
linux people have this problem...?

sorry that i can't help more... ciao, -sciss-

Am 14.05.2009 um 14:08 schrieb Holger Ballweg:

> hm, ok, this seems to be some strange build issue with  
> supercollider on archlinux.
> because the package i built for svn rev 9042 (on april 10th) works  
> fine with swingosc,
> as well as when i took the build of today and overwrote /usr/lib/ 
> libsclang.so with one from an ubuntu jaunty package....
> :-/
>
>
> On Thu, May 14, 2009 at 4:20 AM, James Harkins  
> <jam...@gm...> wrote:
> Working fine here (rev 181).
>
> Maybe add a debugging statement to SwingOSC:listSendBundle, to find  
> out what the list really is?
> hjh
>
>
> On May 13, 2009, at 6:44 PM, Holger Ballweg wrote:
>
>> Hi folks,
>>
>> I have some strange problems with swingosc SVN174 & 181:
>> I get this error when I try to display any GUI element:
>>
>> ERROR: List array not an Array.
>> Instance of Array {    (B7916900, gc=10, fmt=01, flg=00, set=03)
>>   indexed slots [2]
>>       0 : instance of Array (B7911BC0, size=7, set=3)
>>       1 : instance of Array (B7915FA0, size=7, set=3)
>> }
>> ERROR: Primitive '_ObjectPerformList' failed.
>> Wrong type.
>> RECEIVER:
>> Instance of NetAddr {    (09E0DDB0, gc=14, fmt=00, flg=00, set=02)
>>   instance variables [4]
>>     addr : Integer 2130706433
>>     port : Integer 57111
>>     hostname : "127.0.0.1"
>>     socket : RawPointer 9DEF858
>> }
>> CALL STACK:
>>     MethodError:reportError   B790BC20
>>         arg this = <instance of PrimitiveFailedError>
>>     Nil:handleError   B79B57C0
>>         arg this = nil
>>         arg error = <instance of PrimitiveFailedError>
>>     Thread:handleError   B7910720
>>         arg this = <instance of Thread>
>>         arg error = <instance of PrimitiveFailedError>
>>     Object:throw   B790C880
>>         arg this = <instance of PrimitiveFailedError>
>>     Object:primitiveFailed   B7907C00
>>         arg this = <instance of NetAddr>
>>     SwingOSC:listSendBundle   B7919A20
>>         arg this = <instance of SwingOSC>
>>         arg time = nil
>>         arg msgs = <instance of List>
>>     JSCTopView:prSCViewNew   B7965CA0
>>         arg this = <instance of JSCTopView>
>>         arg preMsg = nil
>>         arg postMsg = nil
>>         var bndl = <instance of List>
>>         var argBounds = nil
>>     JSCTopView:prInitTopView   B7965D60
>>         arg this = <instance of JSCTopView>
>>         arg argWindow = <instance of JSCWindow>
>>         arg argBounds = <instance of Rect>
>>         arg id = 1007
>>     JSCWindow:prInit   B7966040
>>         arg this = <instance of JSCWindow>
>>         arg argName = "Help browser"
>>         arg argBounds = <instance of Rect>
>>         arg resizable = true
>>         arg border = true
>>         arg scroll = false
>>         var viewID = 1007
>>         var bndl = [*2]
>>     JSCWindow:initSCWindow   B79660E0
>>         arg this = <instance of JSCWindow>
>>         arg argName = "Help browser"
>>         arg argBounds = <instance of Rect>
>>         arg argResizable = true
>>         arg argBorder = true
>>         arg scroll = false
>>         arg argServer = <instance of SwingOSC>
>>     Help:gui   0A752A30
>>         arg this = <instance of Help>
>>         arg sysext = true
>>         arg userext = true
>>         arg allowCached = true
>>         var classes = nil
>>         var win = nil
>>         var lists = nil
>>         var listviews = nil
>>         var numcols = 7
>>         var selecteditem = nil
>>         var node = nil
>>         var newlist = nil
>>         var curkey = nil
>>         var selectednodes = nil
>>         var scrollView = nil
>>         var compView = nil
>>         var textView = nil
>>         var keys = nil
>>         var classButt = nil
>>         var browseButt = nil
>>         var bwdButt = nil
>>         var fwdButt = nil
>>         var isClass = nil
>>         var history = [*0]
>>         var historyIdx = 0
>>         var fBwdFwd = nil
>>         var fHistoryDo = nil
>>         var fHistoryMove = nil
>>         var screenBounds = <instance of Rect>
>>         var bounds = <instance of Rect>
>>         var textViewBounds = nil
>>         var results = nil
>>         var resultsview = nil
>>         var statictextloc = nil
>>         var searchField = nil
>>         var helpguikeyacts = nil
>>         var fSelectTreePath = nil
>>         var inPathSelect = false
>>         var fUpdateWinTitle = nil
>>         var fLoadError = nil
>>     Interpreter:interpretPrintCmdLine   B7966220
>>         arg this = <instance of Interpreter>
>>         var res = nil
>>         var func = <instance of Function>
>>         var code = "Help.gui"
>>         var doc = <instance of ScelDocument>
>>     Process:interpretPrintCmdLine   B7918E50
>>         arg this = <instance of Main>
>>
>>
>> (in this example Help.gui :-)
>>
>> I don`t really know what to do... This happens both with  
>> SuperCollider 3.3, 3.2 & today`s SVN,
>> with the jdk from sun (v 6u13-1) and with openjdk (v  
>> 1.5_hg20090429-1)
>>
>> Any help would be appreciated :-)
>>
>> Cheers,
>>
>> Holger
>
>
> : H. James Harkins
> : jam...@de...
> : http://www.dewdrop-world.net
> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
>
>
> ---------------------------------------------------------------------- 
> --------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
> Your
> production scanning environment may not be a perfect world - but  
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW  
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Swingosc-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swingosc-devel
>
>
> ---------------------------------------------------------------------- 
> --------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
> Your
> production scanning environment may not be a perfect world - but  
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW  
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak- 
> com_______________________________________________
> Swingosc-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swingosc-devel

Re: [Swingosc-devel] strange problems with swingosc

[Holger B. <mor...@go...>]

hm, ok, this seems to be some strange build issue with supercollider on
archlinux.
because the package i built for svn rev 9042 (on april 10th) works fine with
swingosc,
as well as when i took the build of today and overwrote
/usr/lib/libsclang.so with one from an ubuntu jaunty package....
:-/


On Thu, May 14, 2009 at 4:20 AM, James Harkins <jam...@gm...> wrote:

>  Working fine here (rev 181).
>
> Maybe add a debugging statement to SwingOSC:listSendBundle, to find out
> what the list really is?
> hjh
>
>
> On May 13, 2009, at 6:44 PM, Holger Ballweg wrote:
>
> Hi folks,
>
> I have some strange problems with swingosc SVN174 & 181:
> I get this error when I try to display any GUI element:
>
> ERROR: List array not an Array.
> Instance of Array {    (B7916900, gc=10, fmt=01, flg=00, set=03)
>   indexed slots [2]
>       0 : instance of Array (B7911BC0, size=7, set=3)
>       1 : instance of Array (B7915FA0, size=7, set=3)
> }
> ERROR: Primitive '_ObjectPerformList' failed.
> Wrong type.
> RECEIVER:
> Instance of NetAddr {    (09E0DDB0, gc=14, fmt=00, flg=00, set=02)
>   instance variables [4]
>     addr : Integer 2130706433
>     port : Integer 57111
>     hostname : "127.0.0.1"
>     socket : RawPointer 9DEF858
> }
> CALL STACK:
>     MethodError:reportError   B790BC20
>         arg this = <instance of PrimitiveFailedError>
>     Nil:handleError   B79B57C0
>         arg this = nil
>         arg error = <instance of PrimitiveFailedError>
>     Thread:handleError   B7910720
>         arg this = <instance of Thread>
>         arg error = <instance of PrimitiveFailedError>
>     Object:throw   B790C880
>         arg this = <instance of PrimitiveFailedError>
>     Object:primitiveFailed   B7907C00
>         arg this = <instance of NetAddr>
>     SwingOSC:listSendBundle   B7919A20
>         arg this = <instance of SwingOSC>
>         arg time = nil
>         arg msgs = <instance of List>
>     JSCTopView:prSCViewNew   B7965CA0
>         arg this = <instance of JSCTopView>
>         arg preMsg = nil
>         arg postMsg = nil
>         var bndl = <instance of List>
>         var argBounds = nil
>     JSCTopView:prInitTopView   B7965D60
>         arg this = <instance of JSCTopView>
>         arg argWindow = <instance of JSCWindow>
>         arg argBounds = <instance of Rect>
>         arg id = 1007
>     JSCWindow:prInit   B7966040
>         arg this = <instance of JSCWindow>
>         arg argName = "Help browser"
>         arg argBounds = <instance of Rect>
>         arg resizable = true
>         arg border = true
>         arg scroll = false
>         var viewID = 1007
>         var bndl = [*2]
>     JSCWindow:initSCWindow   B79660E0
>         arg this = <instance of JSCWindow>
>         arg argName = "Help browser"
>         arg argBounds = <instance of Rect>
>         arg argResizable = true
>         arg argBorder = true
>         arg scroll = false
>         arg argServer = <instance of SwingOSC>
>     Help:gui   0A752A30
>         arg this = <instance of Help>
>         arg sysext = true
>         arg userext = true
>         arg allowCached = true
>         var classes = nil
>         var win = nil
>         var lists = nil
>         var listviews = nil
>         var numcols = 7
>         var selecteditem = nil
>         var node = nil
>         var newlist = nil
>         var curkey = nil
>         var selectednodes = nil
>         var scrollView = nil
>         var compView = nil
>         var textView = nil
>         var keys = nil
>         var classButt = nil
>         var browseButt = nil
>         var bwdButt = nil
>         var fwdButt = nil
>         var isClass = nil
>         var history = [*0]
>         var historyIdx = 0
>         var fBwdFwd = nil
>         var fHistoryDo = nil
>         var fHistoryMove = nil
>         var screenBounds = <instance of Rect>
>         var bounds = <instance of Rect>
>         var textViewBounds = nil
>         var results = nil
>         var resultsview = nil
>         var statictextloc = nil
>         var searchField = nil
>         var helpguikeyacts = nil
>         var fSelectTreePath = nil
>         var inPathSelect = false
>         var fUpdateWinTitle = nil
>         var fLoadError = nil
>     Interpreter:interpretPrintCmdLine   B7966220
>         arg this = <instance of Interpreter>
>         var res = nil
>         var func = <instance of Function>
>         var code = "Help.gui"
>         var doc = <instance of ScelDocument>
>     Process:interpretPrintCmdLine   B7918E50
>         arg this = <instance of Main>
>
>
> (in this example Help.gui :-)
>
> I don`t really know what to do... This happens both with SuperCollider 3.3,
> 3.2 & today`s SVN,
> with the jdk from sun (v 6u13-1<http://aur.archlinux.org/packages.php?ID=6121>)
> and with openjdk (v 1.5_hg20090429-1)
>
> Any help would be appreciated :-)
>
> Cheers,
>
> Holger
>
>
>
> : H. James Harkins
> : jam...@de...
> : http://www.dewdrop-world.net
> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
>
>
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Swingosc-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swingosc-devel
>
>

Re: [Swingosc-devel] strange problems with swingosc

[James H. <jam...@gm...>]

Working fine here (rev 181).

Maybe add a debugging statement to SwingOSC:listSendBundle, to find  
out what the list really is?
hjh


On May 13, 2009, at 6:44 PM, Holger Ballweg wrote:

> Hi folks,
>
> I have some strange problems with swingosc SVN174 & 181:
> I get this error when I try to display any GUI element:
>
> ERROR: List array not an Array.
> Instance of Array {    (B7916900, gc=10, fmt=01, flg=00, set=03)
>   indexed slots [2]
>       0 : instance of Array (B7911BC0, size=7, set=3)
>       1 : instance of Array (B7915FA0, size=7, set=3)
> }
> ERROR: Primitive '_ObjectPerformList' failed.
> Wrong type.
> RECEIVER:
> Instance of NetAddr {    (09E0DDB0, gc=14, fmt=00, flg=00, set=02)
>   instance variables [4]
>     addr : Integer 2130706433
>     port : Integer 57111
>     hostname : "127.0.0.1"
>     socket : RawPointer 9DEF858
> }
> CALL STACK:
>     MethodError:reportError   B790BC20
>         arg this = <instance of PrimitiveFailedError>
>     Nil:handleError   B79B57C0
>         arg this = nil
>         arg error = <instance of PrimitiveFailedError>
>     Thread:handleError   B7910720
>         arg this = <instance of Thread>
>         arg error = <instance of PrimitiveFailedError>
>     Object:throw   B790C880
>         arg this = <instance of PrimitiveFailedError>
>     Object:primitiveFailed   B7907C00
>         arg this = <instance of NetAddr>
>     SwingOSC:listSendBundle   B7919A20
>         arg this = <instance of SwingOSC>
>         arg time = nil
>         arg msgs = <instance of List>
>     JSCTopView:prSCViewNew   B7965CA0
>         arg this = <instance of JSCTopView>
>         arg preMsg = nil
>         arg postMsg = nil
>         var bndl = <instance of List>
>         var argBounds = nil
>     JSCTopView:prInitTopView   B7965D60
>         arg this = <instance of JSCTopView>
>         arg argWindow = <instance of JSCWindow>
>         arg argBounds = <instance of Rect>
>         arg id = 1007
>     JSCWindow:prInit   B7966040
>         arg this = <instance of JSCWindow>
>         arg argName = "Help browser"
>         arg argBounds = <instance of Rect>
>         arg resizable = true
>         arg border = true
>         arg scroll = false
>         var viewID = 1007
>         var bndl = [*2]
>     JSCWindow:initSCWindow   B79660E0
>         arg this = <instance of JSCWindow>
>         arg argName = "Help browser"
>         arg argBounds = <instance of Rect>
>         arg argResizable = true
>         arg argBorder = true
>         arg scroll = false
>         arg argServer = <instance of SwingOSC>
>     Help:gui   0A752A30
>         arg this = <instance of Help>
>         arg sysext = true
>         arg userext = true
>         arg allowCached = true
>         var classes = nil
>         var win = nil
>         var lists = nil
>         var listviews = nil
>         var numcols = 7
>         var selecteditem = nil
>         var node = nil
>         var newlist = nil
>         var curkey = nil
>         var selectednodes = nil
>         var scrollView = nil
>         var compView = nil
>         var textView = nil
>         var keys = nil
>         var classButt = nil
>         var browseButt = nil
>         var bwdButt = nil
>         var fwdButt = nil
>         var isClass = nil
>         var history = [*0]
>         var historyIdx = 0
>         var fBwdFwd = nil
>         var fHistoryDo = nil
>         var fHistoryMove = nil
>         var screenBounds = <instance of Rect>
>         var bounds = <instance of Rect>
>         var textViewBounds = nil
>         var results = nil
>         var resultsview = nil
>         var statictextloc = nil
>         var searchField = nil
>         var helpguikeyacts = nil
>         var fSelectTreePath = nil
>         var inPathSelect = false
>         var fUpdateWinTitle = nil
>         var fLoadError = nil
>     Interpreter:interpretPrintCmdLine   B7966220
>         arg this = <instance of Interpreter>
>         var res = nil
>         var func = <instance of Function>
>         var code = "Help.gui"
>         var doc = <instance of ScelDocument>
>     Process:interpretPrintCmdLine   B7918E50
>         arg this = <instance of Main>
>
>
> (in this example Help.gui :-)
>
> I don`t really know what to do... This happens both with  
> SuperCollider 3.3, 3.2 & today`s SVN,
> with the jdk from sun (v 6u13-1) and with openjdk (v 1.5_hg20090429-1)
>
> Any help would be appreciated :-)
>
> Cheers,
>
> Holger


: H. James Harkins
: jam...@de...
: http://www.dewdrop-world.net
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

[Swingosc-devel] strange problems with swingosc

[Holger B. <mor...@go...>]

Hi folks,

I have some strange problems with swingosc SVN174 & 181:
I get this error when I try to display any GUI element:

ERROR: List array not an Array.
Instance of Array {    (B7916900, gc=10, fmt=01, flg=00, set=03)
  indexed slots [2]
      0 : instance of Array (B7911BC0, size=7, set=3)
      1 : instance of Array (B7915FA0, size=7, set=3)
}
ERROR: Primitive '_ObjectPerformList' failed.
Wrong type.
RECEIVER:
Instance of NetAddr {    (09E0DDB0, gc=14, fmt=00, flg=00, set=02)
  instance variables [4]
    addr : Integer 2130706433
    port : Integer 57111
    hostname : "127.0.0.1"
    socket : RawPointer 9DEF858
}
CALL STACK:
    MethodError:reportError   B790BC20
        arg this = <instance of PrimitiveFailedError>
    Nil:handleError   B79B57C0
        arg this = nil
        arg error = <instance of PrimitiveFailedError>
    Thread:handleError   B7910720
        arg this = <instance of Thread>
        arg error = <instance of PrimitiveFailedError>
    Object:throw   B790C880
        arg this = <instance of PrimitiveFailedError>
    Object:primitiveFailed   B7907C00
        arg this = <instance of NetAddr>
    SwingOSC:listSendBundle   B7919A20
        arg this = <instance of SwingOSC>
        arg time = nil
        arg msgs = <instance of List>
    JSCTopView:prSCViewNew   B7965CA0
        arg this = <instance of JSCTopView>
        arg preMsg = nil
        arg postMsg = nil
        var bndl = <instance of List>
        var argBounds = nil
    JSCTopView:prInitTopView   B7965D60
        arg this = <instance of JSCTopView>
        arg argWindow = <instance of JSCWindow>
        arg argBounds = <instance of Rect>
        arg id = 1007
    JSCWindow:prInit   B7966040
        arg this = <instance of JSCWindow>
        arg argName = "Help browser"
        arg argBounds = <instance of Rect>
        arg resizable = true
        arg border = true
        arg scroll = false
        var viewID = 1007
        var bndl = [*2]
    JSCWindow:initSCWindow   B79660E0
        arg this = <instance of JSCWindow>
        arg argName = "Help browser"
        arg argBounds = <instance of Rect>
        arg argResizable = true
        arg argBorder = true
        arg scroll = false
        arg argServer = <instance of SwingOSC>
    Help:gui   0A752A30
        arg this = <instance of Help>
        arg sysext = true
        arg userext = true
        arg allowCached = true
        var classes = nil
        var win = nil
        var lists = nil
        var listviews = nil
        var numcols = 7
        var selecteditem = nil
        var node = nil
        var newlist = nil
        var curkey = nil
        var selectednodes = nil
        var scrollView = nil
        var compView = nil
        var textView = nil
        var keys = nil
        var classButt = nil
        var browseButt = nil
        var bwdButt = nil
        var fwdButt = nil
        var isClass = nil
        var history = [*0]
        var historyIdx = 0
        var fBwdFwd = nil
        var fHistoryDo = nil
        var fHistoryMove = nil
        var screenBounds = <instance of Rect>
        var bounds = <instance of Rect>
        var textViewBounds = nil
        var results = nil
        var resultsview = nil
        var statictextloc = nil
        var searchField = nil
        var helpguikeyacts = nil
        var fSelectTreePath = nil
        var inPathSelect = false
        var fUpdateWinTitle = nil
        var fLoadError = nil
    Interpreter:interpretPrintCmdLine   B7966220
        arg this = <instance of Interpreter>
        var res = nil
        var func = <instance of Function>
        var code = "Help.gui"
        var doc = <instance of ScelDocument>
    Process:interpretPrintCmdLine   B7918E50
        arg this = <instance of Main>


(in this example Help.gui :-)

I don`t really know what to do... This happens both with SuperCollider 3.3,
3.2 & today`s SVN,
with the jdk from sun (v 6u13-1<http://aur.archlinux.org/packages.php?ID=6121>)
and with openjdk (v 1.5_hg20090429-1)

Any help would be appreciated :-)

Cheers,

Holger

Re: [Swingosc-devel] patch for EZ behaviour

[nescivi <ne...@gm...>]

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-

Re: [Swingosc-devel] patch for EZ behaviour

[nescivi <ne...@gm...>]

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-

Re: [Swingosc-devel] patch for EZ behaviour

[Sciss <co...@sc...>]

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-
>

Re: [Swingosc-devel] patch for EZ behaviour

[Sciss <co...@sc...>]

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

Re: [Swingosc-devel] patch for EZ behaviour

[nescivi <ne...@gm...>]

Hiho,

how about this diff?

sincerely,
Marije

Re: [Swingosc-devel] patch for EZ behaviour

[nescivi <ne...@gm...>]

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

Re: [Swingosc-devel] patch for EZ behaviour

[Sciss <co...@sc...>]

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

[Swingosc-devel] patch for EZ behaviour

[nescivi <ne...@gm...>]

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

Re: [Swingosc-devel] window.isClosed at swingosc quit

[Sciss <co...@sc...>]

hi,

looking into this, it was already there...... in JSCWindow.prInit:

		updServer = UpdateListener.newFor( server, { arg upd, s;
			if( s.serverRunning.not, { this.close });
		}, \serverRunning );

i can't remember when it was added, but can you check the following  
works for you:


g.boot;

w = JSCWindow.new.front.onClose_({ "Closed!".postln });

g.quit;	// --> prints!


if it prints, i think we don't need to change anything.

ciao, -sciss-


Am 03.04.2009 um 18:15 schrieb nescivi:

> Hiho,
>
> On Monday 23 March 2009 10:43:17 Sc iss wrote:
>> UpdateListener.newFor( g, { arg upd, swing; if 
>> ( swing.serverRunning.not, {
>> upd.remove; JSCWindow.allWindows.select( _.server == swing ).do 
>> ( _.close
>> )})}, \serverRunning );
>
>
> I think it would be useful to have this as a default.
>
>
> sincerely,
> Marije
>
> ---------------------------------------------------------------------- 
> --------
> _______________________________________________
> Swingosc-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swingosc-devel

[Swingosc-devel] added some Linux installation scripts

[nescivi <ne...@gm...>]

Hiho,

I just committed a few scripts to make installation on Linux a bit easier, as 
well as a INSTALL_LINUX file with info about this.

sincerely,
Marije