Here are two patches for g_editor.c that fix following issues in 0.42.5:

1) undo recreates patch cords with wrong color (I posted this one earlier by mistake on the pd-list)

2) graph on parent (GOP) enable and then immediately disable crashes patches that haven't been closed prior to disabling GOP (to reproduce, open new patch->right-click->properties->enable gop->apply->disable gop->apply->crash). This one may also affect pd vanilla (haven't checked)

Best wishes,

ico

Below is relevant excerpt that IMHO is much better scrolling algorithm. It has been tested only on Linux so far but there is no reason why it should not work on other platforms. Basically, now the whole canvas translates as necessary. Therefore,

1) dragging a single object away from 0 0 coordinates will never spawn a scrollbar (since we don't care how far someone goes away from center--theoretically their whole patch could be at -30000 to -29800 (x1 x2). That said, I am not sure if the thing will crash if you go beyond 1.0e30 either direction but I suspect it will take a long while before you get there :-) 2) scrollbars appear/disappear logically, (e.g. only when two or more objects are far enough from each other not to fit on the visible portion of the canvas) 3) and perhaps most importantly since text (particularly larger text commonly used for iemlib gui elements) generates incorrect reports from the "bbox all" call (e.g. try creating a number2 with a height 80 and notice how you are never able to drag it all the way to the top of the canvas without invoking the Y-axis scrollbar even though your text might be font 10; larger font sizes make things even worse). So now finally I can create compact windows without scrollbars using iemlib objects.

Optionally, if you wish to use hacked pd.tk version (made for pd-extended 0.42.5). You will also have an option to disable scrollbars, menu, alter background color, toggle ontop, and disable resize, *per patcher*. I found this to be also rather useful for GUI creation. Attached with the new pd.tk are supporting abstractions.

Below is relevant code for points 1-3 from the current pd.tk in hope it will find its way into 0.43 gui rewrite.

proc pdtk_canvas_getscroll {name} { global pdtk_canvas_mouseup_name global pdtk_canvas_mouseup_xminval global pdtk_canvas_mouseup_xmaxval global pdtk_canvas_mouseup_yminval global pdtk_canvas_mouseup_ymaxval

#bbox all is not accurate enough #particularly when using large iemlib objects #so we calculate canvas size manually #set size [$name bbox all]

#borrowed from http://wiki.tcl.tk/4844 set x1 1.0e30; set x2 -1.0e30 ; set y1 1.0e30; set y2 -1.0e30 ; foreach item [$name find all] { switch -exact [$name type $item] { "arc" - "line" - "oval" - "polygon" - "rectangle" { set coords [$name coords $item] foreach {x y} $coords { if { $x < $x1 } {set x1 $x} if { $x > $x2 } {set x2 $x} if { $y < $y1 } {set y1 $y} if { $y > $y2 } {set y2 $y} } } } } if {$x1 != 1.0e30} {

set xminval 0 set yminval 0 set xmaxval 100 set ymaxval 20 #set x1 [lindex $size 0] #set x2 [lindex $size 2] #set y1 [lindex $size 1] #set y2 [lindex $size 3]

#pdtk_post "bbox all: $x1 $x2 $y1 $y2\n" #pdtk_post "new bbox all: $xbox1 $xbox2 $ybox1 $ybox2\n"

#these work much better than the ones below #they allow for intelligent translation of the canvas #rather than introducing redundant scrollbars set xminval $x1 set yminval $y1

set xmaxval [expr $x1+($x2-$x1)] set ymaxval [expr $y1+($y2-$y1)]

#if {$x1 < $xminval} {set xminval $x1} #if {$y1 < $yminval} {set yminval $y1}

#if {$x2 > $xmaxval} {set xmaxval $x2} #if {$y2 > $ymaxval} {set ymaxval $y2}

#pdtk_post "$xminval $xmaxval $yminval $ymaxval\n"

set parentname [winfo parent $name] set winwidth [winfo width $parentname] set winheight [winfo height $parentname]

set canvaswidth [ expr {abs($xmaxval-$xminval)} ] set canvasheight [ expr {abs($ymaxval-$yminval)} ] #set canvaswidth [ expr {abs($xminval)+$xmaxval} ] #set canvasheight [ expr {abs($yminval)+$ymaxval} ]

#pdtk_post "$canvaswidth $canvasheight\n"

#pdtk_post "$parentname [$parentname.scroll cget -state]\n" if {$::scroll($parentname) == 1} { #pdtk_post "scroll=yes $winwidth $canvaswidth\n" if {$winwidth > $canvaswidth} {pack forget $parentname.scrollhort} if {$winheight > $canvasheight} {pack forget $parentname.scrollvert} if {$winwidth < $canvaswidth} {pack $parentname.scrollhort -fill x \ -side bottom -before $parentname.c} if {$winheight < $canvasheight} {pack $parentname.scrollvert -fill y \ -side right -before $parentname.c} } if {$pdtk_canvas_mouseup_name != $name || \ $pdtk_canvas_mouseup_xminval != $xminval || \ $pdtk_canvas_mouseup_xmaxval != $xmaxval || \ $pdtk_canvas_mouseup_yminval != $yminval || \ $pdtk_canvas_mouseup_ymaxval != $ymaxval } { set newsize "$xminval $yminval $xmaxval $ymaxval" $name configure -scrollregion $newsize set pdtk_canvas_mouseup_name $name set pdtk_canvas_mouseup_xminval $xminval set pdtk_canvas_mouseup_xmaxval $xmaxval set pdtk_canvas_mouseup_yminval $yminval set pdtk_canvas_mouseup_ymaxval $ymaxval } } pdtk_canvas_checkgeometry [canvastosym $name] }

Best wishes,

Ico

On Sat, 2009-10-31 at 17:18 -0400, Hans-Christoph Steiner wrote:

Hey Ivica,

I rewrote the scrollbar logic in 0.43 and its working well, as far as I can tell. Have you tried it out? I think its a similar approach, but the difference is that my code tries to keep things at 0,0 since Pd has a historical preference for patches having 0,0 as the upper left.

.hc

I see. After I've played with the 0.43 and here are a couple reasons why I feel this implementation is still (IMHO) better:

1) it seems does that the canvas does not create scrollbars until you let go of an object. So if you do go off-canvas, the scrollbar does not appear until you do mouse-up. I personally find this distracting as the canvas does not update dynamically. This is not the case with the submitted patch.

2) more importantly, pd-gui-rewrite still suffers from miscalculated "bbox all" size which this patch also addresses. e.g. try creating a number2 object and adjust its height to 80 (top-right value on the properties window). Now drag it all the way up and it can never reach the edge of the top side of the canvas (or any other side for that matter, depending upon the width parameter) due to miscalculated size (bbox accounts for text as well and text through this process scales incorrectly according to this tk post: http://wiki.tcl.tk/4844). Of course, not everyone needs size 80 number2 box but this discrepancy is present at all sizes--it is just less noticeable at smaller ones as in those cases rectangle around the text is much closer to the text size if not greater. In other words, with greater size value, the text size grows faster than the size of graphical elements (rectangles, lines, etc.).

3) 0 0 coordinate-centric design IMHO does not make sense. From historical perspective, old patches should still TTBOMK open just fine. Yet, if 0 0 approach is still imposed, it results in unintuitive behavior of scrollbars. e.g. try the following on 0.43 (or previous versions without the suggested patch):

create an object->create another object and slide it to the right until it goes outside the canvas area->a horizontal scrollbar will indicate there is more stuff to the right->scroll to the right and at this point you may find both of your objects (effectively your whole patch) within the canvas, yet the scrollbar will suggest there is something to the left when there isn't.

This has in my opinion been rather distracting while building patches, particularly when dealing with patch GUI design, so much so that I resorted to creating "disable scrollbars" option (see my other email). But even this does not guarantee proper behavior. OTOH, my implementation does tend to pack everything to the top left corner, but at least this way you have an option of putting a canvas object (or some other more functional and less GUI-oriented object) in the top left corner and you will always meet expected results upon reopening your patch.

On a side-note, the new gtk look on the 0.43 is too large for netbook screens (1024x600). e.g. iem object properties do not fit. The proposed version of the older pd.tk takes care of this without sacrificing (obviously IMHO) readability/usability.

Many thanks for all your feedback and support! Keep up the great work!

Best wishes,

Ico

On Oct 31, 2009, at 9:41 PM, Ivica Ico Bukvic wrote:

...

3. 0 0 coordinate-centric design IMHO does not make sense. From

historical perspective, old patches should still TTBOMK open just fine. Yet, if 0 0 approach is still imposed, it results in unintuitive behavior of scrollbars. e.g. try the following on 0.43 (or previous versions without the suggested patch):

create an object->create another object and slide it to the right until it goes outside the canvas area->a horizontal scrollbar will indicate there is more stuff to the right->scroll to the right and at this point you may find both of your objects (effectively your whole patch) within the canvas, yet the scrollbar will suggest there is something to the left when there isn't.

After testing this a bit more, here's a small correction. My implementation does pack everything to the right or the left depending upon where the whole canvas is located in respect to the 0 0 coord. This does not however affect older patches. That said, I still feel this is more desirable and ultimately can be further adjusted as necessary.

Best wishes,

Ico

I wanted to try this now that I have a moment, but I couldn't find the patch. Did you add it to the patch tracker?

.hc

----------------------------------------------------------------------------

Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra

Ah, ok, just comparing now. I added this pdtk_canvas-getscroll to Pd- extended 0.42.5-2009-11-12. We currently have four to compare: Ico's, Pd, Pd-extended, and Pd-Gui-Rewrite.

- Pd-extended will correctly handle the scrollbars if you select some objects and move them with Shift-arrow, the other three do not (some better than others)

- when you select all and mouse drag components out of the current view, Pd-extended updates scrollbars immediately, Pd and Pd-devel update the scrollbars once you release the mouse, and Ico's gave me an error saying "Error: can't read "::scroll(.x6d5610)"

- when you resize the window, Pd-devel updates the scrollbars live, Pd- extended updates live with glitches, Pd updates on release, Ico's gave me an error saying "Error: can't read "::scroll(.x6d5610)"

.hc

On Nov 18, 2009, at 12:17 AM, Miller Puckette wrote:

I think it's only in the e-mail:

http://lists.puredata.info/pipermail/pd-dev/2009-10/014298.html

On Wed, Nov 18, 2009 at 12:12:50AM -0500, Hans-Christoph Steiner wrote:

...

On Oct 31, 2009, at 9:41 PM, Ivica Ico Bukvic wrote:

...

...

3. 0 0 coordinate-centric design IMHO does not make sense. From

historical perspective, old patches should still TTBOMK open just fine. Yet, if 0 0 approach is still imposed, it results in unintuitive behavior of scrollbars. e.g. try the following on 0.43 (or previous versions without the suggested patch):

create an object->create another object and slide it to the right until it goes outside the canvas area->a horizontal scrollbar will indicate there is more stuff to the right->scroll to the right and at this point you may find both of your objects (effectively your whole patch) within the canvas, yet the scrollbar will suggest there is something to the left when there isn't.

After testing this a bit more, here's a small correction. My implementation does pack everything to the right or the left depending upon where the whole canvas is located in respect to the 0 0 coord. This does not however affect older patches. That said, I still feel this is more desirable and ultimately can be further adjusted as necessary.

Best wishes,

Ico

I wanted to try this now that I have a moment, but I couldn't find the patch. Did you add it to the patch tracker?

.hc

---

Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

----------------------------------------------------------------------------

If you are not part of the solution, you are part of the problem.

OK, try the one below instead (with ::scroll call removed). Also, plase don't forget to do the followign test with large graphics objects and test scrollbar behavior:

1) create iemlib's number2 2) adjust its height to 60 and its font size to 50 3) drag it as far to the top as possible and what you will likely discover is that it fails to reach the top corner *or* creates scrollbars even though the object fits comfortably within the window. This is not the case AFAIK with the version below.

Ico

proc pdtk_canvas_getscroll {name} { global pdtk_canvas_mouseup_name global pdtk_canvas_mouseup_xminval global pdtk_canvas_mouseup_xmaxval global pdtk_canvas_mouseup_yminval global pdtk_canvas_mouseup_ymaxval

#bbox all is not accurate enough #particularly when using large iemlib objects #so we calculate canvas size manually #set size [$name bbox all]

#borrowed from http://wiki.tcl.tk/4844 set x1 1.0e30; set x2 -1.0e30 ; set y1 1.0e30; set y2 -1.0e30 ; foreach item [$name find all] { switch -exact [$name type $item] { "arc" - "line" - "oval" - "polygon" - "rectangle" { set coords [$name coords $item] foreach {x y} $coords { if { $x < $x1 } {set x1 $x} if { $x > $x2 } {set x2 $x} if { $y < $y1 } {set y1 $y} if { $y > $y2 } {set y2 $y} } } } } if {$x1 != 1.0e30} {

set xminval 0 set yminval 0 set xmaxval 100 set ymaxval 20 #set x1 [lindex $size 0] #set x2 [lindex $size 2] #set y1 [lindex $size 1] #set y2 [lindex $size 3]

#pdtk_post "bbox all: $x1 $x2 $y1 $y2\n" #pdtk_post "new bbox all: $xbox1 $xbox2 $ybox1 $ybox2\n"

#these work much better than the ones below #they allow for intelligent translation of the canvas #rather than introducing redundant scrollbars set xminval $x1 set yminval $y1

set xmaxval [expr $x1+($x2-$x1)] set ymaxval [expr $y1+($y2-$y1)]

#if {$x1 < $xminval} {set xminval $x1} #if {$y1 < $yminval} {set yminval $y1}

#if {$x2 > $xmaxval} {set xmaxval $x2} #if {$y2 > $ymaxval} {set ymaxval $y2}

#pdtk_post "$xminval $xmaxval $yminval $ymaxval\n"

set parentname [winfo parent $name] set winwidth [winfo width $parentname] set winheight [winfo height $parentname]

set canvaswidth [ expr {abs($xmaxval-$xminval)} ] set canvasheight [ expr {abs($ymaxval-$yminval)} ] #set canvaswidth [ expr {abs($xminval)+$xmaxval} ] #set canvasheight [ expr {abs($yminval)+$ymaxval} ]

#pdtk_post "$canvaswidth $canvasheight\n"

#pdtk_post "$parentname [$parentname.scroll cget -state]\n"

#pdtk_post "scroll=yes $winwidth $canvaswidth\n" if {$winwidth > $canvaswidth} {pack forget $parentname.scrollhort} if {$winheight > $canvasheight} {pack forget $parentname.scrollvert} if {$winwidth < $canvaswidth} {pack $parentname.scrollhort -fill x \ -side bottom -before $parentname.c} if {$winheight < $canvasheight} {pack $parentname.scrollvert -fill y \ -side right -before $parentname.c}

if {$pdtk_canvas_mouseup_name != $name || \ $pdtk_canvas_mouseup_xminval != $xminval || \ $pdtk_canvas_mouseup_xmaxval != $xmaxval || \ $pdtk_canvas_mouseup_yminval != $yminval || \ $pdtk_canvas_mouseup_ymaxval != $ymaxval } { set newsize "$xminval $yminval $xmaxval $ymaxval" $name configure -scrollregion $newsize set pdtk_canvas_mouseup_name $name set pdtk_canvas_mouseup_xminval $xminval set pdtk_canvas_mouseup_xmaxval $xmaxval set pdtk_canvas_mouseup_yminval $yminval set pdtk_canvas_mouseup_ymaxval $ymaxval } } pdtk_canvas_checkgeometry [canvastosym $name] }

On Nov 1, 2009, at 4:15 AM, Frank Barknecht wrote:

Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

...

I rewrote the scrollbar logic in 0.43 and its working well, as far as I can tell. Have you tried it out? I think its a similar approach, but the difference is that my code tries to keep things at 0,0 since Pd has a historical preference for patches having 0,0 as the upper left.

I cannot check out Ico's patch nor the GUI rewrite in general ATM, but generally all this stuff should always be tested with data structure displaying subpatches we well, as the coordinates there directly reflect the x/ y float field values.

Hey Frank,

Can you suggest a particular patch?

.hc

----------------------------------------------------------------------------

I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup (creator of C++)

oups, sorry (same report as olsen)...

fixed with:

pd/externals/pdp/opengl/include/pdp_texture.h

- bool pdp_packet_texture_isvalid(int packet); + int pdp_packet_texture_isvalid(int packet);

pat