Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
> I guessed that the attached patch illustrates the problem that you are > describing, but it seems to me that the current Pd-extended algorithm > and the Pd-vanilla algorithm get it right: Labels for some reason seem to be more forgiving, but when you increase font size enough, they get messed up too (see test1.pd for an example). The problem is more apparent when using number2 object. See attached test2.pd patch--there should be no scrollbars since the object fits, yet there they are nonetheless. If you make the font size bigger, it gets worse. Ico #N canvas 2 50 450 300 10; #X obj 155 -172 hsl 128 15 0 127 0 0 empty empty BLAH -2 -8 0 30 -262144 -1 -1 0 1; #N canvas 324 50 224 228 10; #X obj 70 -122 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 0 256; ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Dec 4, 2009, at 11:00 PM, Ivica Ico Bukvic wrote: I guess I didn't understand the nature of that issue. I haven't seen it. Tcl/Tk's bbox stuff seems to work with comments, do you mean IEMGUI text? .hc Hans, I really don't mean to be disrespectful but I am really getting frustrated by the fact that you apparently do not read my emails at all, keep asking same questions over and over again, and on top of that fail to perform the task I asked you to perform several times ago to assess the bug. My time is limited as I am sure is yours, but if submitting a patch means repeating myself 4 times and then getting it contested continually on grounds that are entirely irrelevant to the patch itself is becoming really tiring (and yes this patch does not address the mouse wheel but it does not exacerbate the problem either--in other words it is orthogonal to it, so mousewheel has *nothing* to do with this). So, please read them and check out the matter at hand instead of asking for an explanation of the same issue over and over again. Below are emails I sent you explaining in detail the same issue: http://www.mail-archive.com/pd-dev@iem.at/msg07054.html (see point 2) http://www.mail-archive.com/pd-dev@iem.at/msg07123.html http://www.mail-archive.com/pd-dev@iem.at/msg07124.html So, once again, yes, it does affect IEMGUI as it does any other text. The bbox miscalculation essentially affects all sizes but is less apparent at small font sizes, so it (kind of) works (because the discrepancy is not noticeable) as long as you don't use anything but default-sized fonts. If you alter your default font size and/or use iemgui objects the issue will quickly become apparent. Maybe I'm just slow, but I ask because I have been following this thread and I don't understand the details of the problem or the patch. Your emails have not made it clear to me. That's why I started the wiki page, and that's why I ask questions. Its my experience that more emails on a topic often make things less clear, rather than more. Also, submitting code in short, succinct "diff -uw" patches makes it much more to the point and easy to read. Illustrating problems with example patches is much more effective than more email. I guessed that the attached patch illustrates the problem that you are describing, but it seems to me that the current Pd-extended algorithm and the Pd-vanilla algorithm get it right: test.pd Description: Binary data .hc The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
> I guess I didn't understand the nature of that issue. I haven't seen > it. Tcl/Tk's bbox stuff seems to work with comments, do you mean > IEMGUI text? > > .hc Hans, I really don't mean to be disrespectful but I am really getting frustrated by the fact that you apparently do not read my emails at all, keep asking same questions over and over again, and on top of that fail to perform the task I asked you to perform several times ago to assess the bug. My time is limited as I am sure is yours, but if submitting a patch means repeating myself 4 times and then getting it contested continually on grounds that are entirely irrelevant to the patch itself is becoming really tiring (and yes this patch does not address the mouse wheel but it does not exacerbate the problem either--in other words it is orthogonal to it, so mousewheel has *nothing* to do with this). So, please read them and check out the matter at hand instead of asking for an explanation of the same issue over and over again. Below are emails I sent you explaining in detail the same issue: http://www.mail-archive.com/pd-dev@iem.at/msg07054.html (see point 2) http://www.mail-archive.com/pd-dev@iem.at/msg07123.html http://www.mail-archive.com/pd-dev@iem.at/msg07124.html So, once again, yes, it does affect IEMGUI as it does any other text. The bbox miscalculation essentially affects all sizes but is less apparent at small font sizes, so it (kind of) works (because the discrepancy is not noticeable) as long as you don't use anything but default-sized fonts. If you alter your default font size and/or use iemgui objects the issue will quickly become apparent. Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
I guess I didn't understand the nature of that issue. I haven't seen it. Tcl/Tk's bbox stuff seems to work with comments, do you mean IEMGUI text? .hc On Dec 4, 2009, at 2:06 PM, Ivica Ico Bukvic wrote: Please see the patch. It says there. I also sent you on several email test that you should do to assess the problem of text size being misrepresented by tcl tk's bbox call. Ico Hans-Christoph Steiner wrote: On Dec 4, 2009, at 7:56 AM, Ivica Ico Bukvic wrote: please see attached patch. it applies cleanly against 0.41.4 extended as well as 0.42.5 extended. ico It works for me Pd-extended 0.42.5-20091112, thanks for that. Sorry for the delay, its been a busy week. Two things I tried: - like the current Pd-extended scroll logic, scrolling with the wheel moves the patch when there are no scrollbars, except it'll scroll the patch contents out of the visible area and not add scrollbars. I've not touched this part. This is simply how 0.42.5 does scrolling in respect to the mouse wheel so I would say this part has nothing to do with my patch... Ah, ok, didn't realize you weren't changing that. IMHO, if we are going to look at scrolling, we need to look at the whole picture. This is bad behavior that should be fixed. That's why I started this dev wiki page, to make a catalog of the whole picture: http://puredata.info/dev/ScrollBarLogic - resizing the window doesn't seem to track comments, I tried 3.audio.examples/A02.amplitude.pd, the scrollbars don't kick in until I cover the objects. the comments don't seem to affect the scrollbars. I realized this earlier last week as well. This is because I am omitting text in manually calculating bbox to avoid redundant scrollbars which are apparent in all other versions, particularly when using number boxes with larger fonts. I think it would be a good idea to report your experience on this one: namely whether you are getting the same results in this respect so that we have this also covered as part of the algorithm's assessment. That said, I thought a bit about this and I think text can be added in two different ways: 1) by creating an invisible box around them (not sure if canvas supports this) or if there is already one identifying it in the manual bbox calculation. 2) trying to figure out what is the font scaling discrepancy and applying that number to text (once again inside manual bbox calculation since that is the only place you could do so on an individual basis such as this one). What was the problem with using Tcl/Tk's bbox calculations? It'll get the comments automatically, IIRC. .hc Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Dec 4, 2009, at 7:56 AM, Ivica Ico Bukvic wrote: please see attached patch. it applies cleanly against 0.41.4 extended as well as 0.42.5 extended. ico It works for me Pd-extended 0.42.5-20091112, thanks for that. Sorry for the delay, its been a busy week. Two things I tried: - like the current Pd-extended scroll logic, scrolling with the wheel moves the patch when there are no scrollbars, except it'll scroll the patch contents out of the visible area and not add scrollbars. I've not touched this part. This is simply how 0.42.5 does scrolling in respect to the mouse wheel so I would say this part has nothing to do with my patch... Ah, ok, didn't realize you weren't changing that. IMHO, if we are going to look at scrolling, we need to look at the whole picture. This is bad behavior that should be fixed. That's why I started this dev wiki page, to make a catalog of the whole picture: http://puredata.info/dev/ScrollBarLogic - resizing the window doesn't seem to track comments, I tried 3.audio.examples/A02.amplitude.pd, the scrollbars don't kick in until I cover the objects. the comments don't seem to affect the scrollbars. I realized this earlier last week as well. This is because I am omitting text in manually calculating bbox to avoid redundant scrollbars which are apparent in all other versions, particularly when using number boxes with larger fonts. I think it would be a good idea to report your experience on this one: namely whether you are getting the same results in this respect so that we have this also covered as part of the algorithm's assessment. That said, I thought a bit about this and I think text can be added in two different ways: 1) by creating an invisible box around them (not sure if canvas supports this) or if there is already one identifying it in the manual bbox calculation. 2) trying to figure out what is the font scaling discrepancy and applying that number to text (once again inside manual bbox calculation since that is the only place you could do so on an individual basis such as this one). What was the problem with using Tcl/Tk's bbox calculations? It'll get the comments automatically, IIRC. .hc Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
> > please see attached patch. it applies cleanly against 0.41.4 > > extended as > > well as 0.42.5 extended. > > > > ico > > > > It works for me Pd-extended 0.42.5-20091112, thanks for that. Sorry > for the delay, its been a busy week. Two things I tried: > > - like the current Pd-extended scroll logic, scrolling with the wheel > moves the patch when there are no scrollbars, except it'll scroll the > patch contents out of the visible area and not add scrollbars. I've not touched this part. This is simply how 0.42.5 does scrolling in respect to the mouse wheel so I would say this part has nothing to do with my patch... > - resizing the window doesn't seem to track comments, I tried > 3.audio.examples/A02.amplitude.pd, the scrollbars don't kick in until > I cover the objects. the comments don't seem to affect the scrollbars. I realized this earlier last week as well. This is because I am omitting text in manually calculating bbox to avoid redundant scrollbars which are apparent in all other versions, particularly when using number boxes with larger fonts. I think it would be a good idea to report your experience on this one: namely whether you are getting the same results in this respect so that we have this also covered as part of the algorithm's assessment. That said, I thought a bit about this and I think text can be added in two different ways: 1) by creating an invisible box around them (not sure if canvas supports this) or if there is already one identifying it in the manual bbox calculation. 2) trying to figure out what is the font scaling discrepancy and applying that number to text (once again inside manual bbox calculation since that is the only place you could do so on an individual basis such as this one). Best wishes, Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Nov 28, 2009, at 11:14 PM, Ivica Ico Bukvic wrote: I have been trying what you have been posting, but I haven't found a clean patch or pd.tk.. The standard format for submitting code to most open source projects is a "diff -uw" patch. That's the best way to submit them if you want people to be able to read them, try them, make sense of them, etc. Check the patches in the patch tracker for examples. I find the easiest way to generate patches is to use "svn diff" please see attached patch. it applies cleanly against 0.41.4 extended as well as 0.42.5 extended. ico It works for me Pd-extended 0.42.5-20091112, thanks for that. Sorry for the delay, its been a busy week. Two things I tried: - like the current Pd-extended scroll logic, scrolling with the wheel moves the patch when there are no scrollbars, except it'll scroll the patch contents out of the visible area and not add scrollbars. - resizing the window doesn't seem to track comments, I tried 3.audio.examples/A02.amplitude.pd, the scrollbars don't kick in until I cover the objects. the comments don't seem to affect the scrollbars. Scrollbars are a pain... .hc I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
> I have been trying what you have been posting, but I haven't found a
> clean patch or pd.tk.. The standard format for submitting code to
> most open source projects is a "diff -uw" patch. That's the best way
> to submit them if you want people to be able to read them, try them,
> make sense of them, etc. Check the patches in the patch tracker for
> examples. I find the easiest way to generate patches is to use "svn
> diff"
please see attached patch. it applies cleanly against 0.41.4 extended as
well as 0.42.5 extended.
ico
--- pd.tk.old 2009-05-22 21:30:00.0 -0400
+++ pd.tk 2009-11-28 23:07:13.0 -0500
@@ -2122,29 +2122,76 @@
global pdtk_canvas_mouseup_yminval
global pdtk_canvas_mouseup_ymaxval
-set size [$name bbox all]
-if {$size != ""} {
+ #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 100
-set x1 [lindex $size 0]
-set x2 [lindex $size 2]
-set y1 [lindex $size 1]
-set y2 [lindex $size 3]
+ 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 < 0} {set xminval $x1}
-if {$y1 < 0} {set yminval $y1}
+ #if {$x1 < $xminval} {set xminval $x1}
+ #if {$y1 < $yminval} {set yminval $y1}
-if {$x2 > 100} {set xmaxval $x2}
-if {$y2 > 100} {set ymaxval $y2}
+ #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($xminval)+$xmaxval} ]
-set canvasheight [ expr {abs($yminval)+$ymaxval} ]
+ 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 \
@@ -2152,6 +2199,7 @@
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 || \
@@ -2166,7 +2214,6 @@
set pdtk_canvas_mouseup_yminval $yminval
set pdtk_canvas_mouseup_ymaxval $ymaxval
}
-
}
pdtk_canvas_checkgeometry [canvastosym $name]
}
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Nov 28, 2009, at 11:35 AM, i...@vt.edu wrote: Please make either a diff/patch with only the scrolling stuff in it, or a version of the pd.tk with only the scrolling changes. If we are talking about the scrolling algorithm, then we should only be talking about that code, not ttk and other things that have nothing to do with scrolling. I did on several occasions, albeit as a replacement function in pd.tk. It should be a matter of a simple copy/paste. I believe you even implemented it as a Pd 0.43 plug-in. Please see my previous emails. Ico Hey Ico, I have been trying what you have been posting, but I haven't found a clean patch or pd.tk.. The standard format for submitting code to most open source projects is a "diff -uw" patch. That's the best way to submit them if you want people to be able to read them, try them, make sense of them, etc. Check the patches in the patch tracker for examples. I find the easiest way to generate patches is to use "svn diff" .hc kill your television ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
> Please make either a diff/patch with only the scrolling stuff in it, > or a version of the pd.tk with only the scrolling changes. If we are > talking about the scrolling algorithm, then we should only be talking > about that code, not ttk and other things that have nothing to do with > scrolling. I did on several occasions, albeit as a replacement function in pd.tk. It should be a matter of a simple copy/paste. I believe you even implemented it as a Pd 0.43 plug-in. Please see my previous emails. Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
Please make either a diff/patch with only the scrolling stuff in it, or a version of the pd.tk with only the scrolling changes. If we are talking about the scrolling algorithm, then we should only be talking about that code, not ttk and other things that have nothing to do with scrolling. .hc On Nov 27, 2009, at 4:21 PM, Ivica Ico Bukvic wrote: Oops, still getting used to the microscopic phone keyboard... BTW if this thing is top-posting, my apologies. It appears the droid leaves me no choice here :-( So, what I was trying to say is that there are two issues at hand here that are mistakenly being interpreted as one. Pd.tk in and of itself has not been submitted for inclusion, but (as per your request) as a means to test new scrolling method. And while the pd.tk in question has a wrapper in place to allow use on both <8.4 and >=8.5 it has not been fully tested nor fully implemented for non-linux platforms. Hene if you wish to test it out as I indicated before, you either need to test it on linux or use updated replacement function in your existing pd.tk I sent out in my earlier email. Reporting any failures of it running otherwise is imho irrelevant to the scrolling algorithm. So, may I suggest that for the sake of clarity, let us not discuss any potential inclusion of pd.tk in this thread, as that clouds the matter at hand which is the scrolling algorithm. Cheers! Ivica Ico Bukvic wrote: I think we are confusing two things here, the whole pd.tk which does offer "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."-John Gilmore ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Fri, 2009-11-27 at 22:15 -0500, Mathieu Bouchard wrote:
> On Fri, 27 Nov 2009, Hans-Christoph Steiner wrote:
>
> > FYI, it doesn't work on Mac OS X because it requires 8.5 and ttk, so this
> > couldn't be included in vanilla since Miller wants to continue to support
> > 8.3, and it couldn't be included in Pd-extended until 0.43 since 0.42
> > doesn't
> > work on Mac OS X with 8.5
>
> if {$::tk_version >= 8.5} ?
Actually, it's even simpler than that. Most of the ttk calls in my
version of pd.tk are ctually old tk calls that are run through
match_linux_wm function which checks for proper pd_nt variable and tk
version and if necessary renames the call to comparable ttk call and
adds customization options. I used the term most instead of all due to
errors Hans has reported which suggest that somewhere along the way I
obviously forgot to do apply the wrapper to all ttk calls.
So, original line in pd.tk looking like:
list frame $name.buttonframe
is converted to:
match_linux_wm [list frame $name.buttonframe]
with the match_linux_wm being:
proc match_linux_wm {list} {
global pd_nt linux_wm_bgcolor linux_wm_hlcolor
if { [info tclversion] >= 8.5 && $pd_nt == 0 } {
if {[lsearch -regexp $list ::] == -1} {
if {[lindex $list 0] != "button" \
&& [lindex $list 0] != "checkbutton" \
&& [lindex $list 0] != "radiobutton" \
&& [lindex $list 0] != "entry" \
&& [lindex $list 0] != "scrollbar"} {
lappend list -bg $linux_wm_bgcolor
}
if {[lindex $list 0] == "listbox" \
|| [lindex $list 0] == "text"} {
lappend list -bg white -highlightcolor
$linux_wm_hlcolor
}
if {[lindex $list 0] == "menu"} {
lappend list -activebackground
$linux_wm_hlcolor -bd 0
}
#convert non-ttk objects to ttk objects
if {[lindex $list 0] == "button" \
|| [lindex $list 0] == "checkbutton" \
|| [lindex $list 0] == "radiobutton" \
|| [lindex $list 0] == "entry" \
|| [lindex $list 0] == "scrollbar"} {
set newlist [lreplace $list 0 0 ttk::[lindex
$list 0]]
}
}
}
if {[info exists newlist]} {
eval $newlist
} else {
eval $list
}
}
So, theoretically once all calls are properly wrapped this is the only
place that the checks need to be done properly and you're done.
Consequently, the new pd.tk should in theory visually affect only linux
users while making no difference whatsoever on other platforms (apart
from scrolling algorithm and other logic-oriented fixes I've made along
the way).
Ico
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Fri, 27 Nov 2009, Ivica Ico Bukvic wrote: It appears the droid leaves me no choice here :-( the droids have won. humanity must surrender control. « 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 _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Fri, 27 Nov 2009, Hans-Christoph Steiner wrote:
FYI, it doesn't work on Mac OS X because it requires 8.5 and ttk, so this
couldn't be included in vanilla since Miller wants to continue to support
8.3, and it couldn't be included in Pd-extended until 0.43 since 0.42 doesn't
work on Mac OS X with 8.5
if {$::tk_version >= 8.5} ?
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
Oops, still getting used to the microscopic phone keyboard... BTW if this thing is top-posting, my apologies. It appears the droid leaves me no choice here :-( So, what I was trying to say is that there are two issues at hand here that are mistakenly being interpreted as one. Pd.tk in and of itself has not been submitted for inclusion, but (as per your request) as a means to test new scrolling method. And while the pd.tk in question has a wrapper in place to allow use on both <8.4 and >=8.5 it has not been fully tested nor fully implemented for non-linux platforms. Hene if you wish to test it out as I indicated before, you either need to test it on linux or use updated replacement function in your existing pd.tk I sent out in my earlier email. Reporting any failures of it running otherwise is imho irrelevant to the scrolling algorithm. So, may I suggest that for the sake of clarity, let us not discuss any potential inclusion of pd.tk in this thread, as that clouds the matter at hand which is the scrolling algorithm. Cheers! Ivica Ico Bukvic wrote: >I think we are confusing two things here, the whole pd.tk which does offer ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
I think we are confusing two things here, the whole pd.tk which does offer Hans-Christoph Steiner wrote: > >On Nov 18, 2009, at 10:47 AM, Ivica Ico Bukvic wrote: > >> Please see attached. This one should work seamlessly on pd-extended >> 0.42.5 with Linux (it has *not* been tested with other platforms even >> though the basic premise of the redesign is that it should). >> >> Ico >> > >FYI, it doesn't work on Mac OS X because it requires 8.5 and ttk, so >this couldn't be included in vanilla since Miller wants to continue to >support 8.3, and it couldn't be included in Pd-extended until 0.43 >since 0.42 doesn't work on Mac OS X with 8.5 > >Error in startup script: invalid command name "ttk::style" > while executing >"ttk::style configure IOErrorOn.TButton -background "#dd"" > (file "/Applications/Pd-0.42.5-extended-20091112.app/Contents/ >Resources/Scripts/AppMain.tcl" line 416) > >.hc > > > > >I hate it when they say, "He gave his life for his country." Nobody >gives their life for anything. We steal the lives of these kids. - >Admiral Gene LeRocque > ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Nov 18, 2009, at 10:47 AM, Ivica Ico Bukvic wrote: Please see attached. This one should work seamlessly on pd-extended 0.42.5 with Linux (it has *not* been tested with other platforms even though the basic premise of the redesign is that it should). Ico FYI, it doesn't work on Mac OS X because it requires 8.5 and ttk, so this couldn't be included in vanilla since Miller wants to continue to support 8.3, and it couldn't be included in Pd-extended until 0.43 since 0.42 doesn't work on Mac OS X with 8.5 Error in startup script: invalid command name "ttk::style" while executing "ttk::style configure IOErrorOn.TButton -background "#dd"" (file "/Applications/Pd-0.42.5-extended-20091112.app/Contents/ Resources/Scripts/AppMain.tcl" line 416) .hc I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
Could you post the full pd.tk and the version of Pd its it supposed to
work with? Also:
- I attached a quick stab at turning your scrollbar logic into a 0.43
GUI plugin. It doesn't work because your code relies on Pd-extended
0.42 things, but if you make your algorithm into a plugin using this
framework, then people can just drop the file into the pd/startup
folder to use your algorithm.
- I created a wiki page to document this whole process, please add any
tests that you can think of here:
http://puredata.info/dev/ScrollBarLogic
.hc
icoscroll-plugin.tcl
Description: Binary data
On Nov 18, 2009, at 10:37 AM, Ivica Ico Bukvic wrote:
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 != $y
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
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_ch
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
> > - 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 I think I now remember why this is--my pdtk has a feature where you can toggle scrollbars, menu, ontop, and background color, per window in a way that retains their properties even if they are temporarily closed (e.g. an embedded patcher). Hence, every window at creation generates global variables that retain that window's properties so if it is a patcher when it is restored, it reflects whatever changes have been made to it. I use abstractions with sys_gui extern to alter these properties (I believe I sent all this out in an email as well). Hence, if you don't wish to use my entire pdtk file, the pdtk_canvas-getscroll I copied in my previous email needs to be filtered to be used, since I have a check in there to skip the whole process if the scrollbars have been disabled. Simply look for lines with ::scroll($name) inside that function and circumvent them. Another thing to test with these pdtks is checking how the detection of borders/enabling of scrollbars is handled with larger fonts and you'll find out that without the fix attached in my pdtk you will get scrollbars when you shouldn't particularly the y one when using large font iemlib number boxes (I think I sent this out in my previous email as well). I'll try to send you an updated version of that method when I get to office. Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > On Nov 1, 2009, at 4:15 AM, Frank Barknecht wrote: >> 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. > > Can you suggest a particular patch? Nothing in particular, but the examples in 4.data.structures provide an ample number of subpatches filled with data structures. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
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. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
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
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
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++) ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
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. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
> 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
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
On Oct 31, 2009, at 3:34 PM, Ivica Ico Bukvic wrote:
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 -3 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 [$par
