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 hans@at.or.at 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
<patch>
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:
- 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.
- 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.
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
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:
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
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
-
Hans-Christoph Steiner -
Ivica Ico Bukvic