Hi list,
From tcl/pd-gui: # we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform tk scaling 1
From #tcl on freenode: <jancsika> hello. does tk scaling affect canvas items? <ijchain> <emiliano> jancsika: no
From my own experiments on Debian: * setting the tk scaling to 1, 0.2, 3, or 200 does not alter a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes * with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200 _will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size.
You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click <ctrl-n> for a new patch and it will look exactly right. Also try:
[label foo( | [vsl]
... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling.
Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont
Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at "1" may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets.
So-- is there any reason not to remove "tk scaling 1"?
Thanks, Jonathan
Hi Jonathan et a -
I've never understood the reason tk_scaling is touched in the TK code and unless someone else objects I'll try taking it out of the vanilla source.
thanks Miller
On Tue, Jun 11, 2013 at 06:11:57PM -0700, Jonathan Wilkes wrote:
Hi list,
From tcl/pd-gui:    # we are not using Tk scaling, so fix it to 1 on all platforms. This    # guarantees that patches will be pixel-exact on every platform    tk scaling 1
From #tcl on freenode: <jancsika> hello. does tk scaling affect canvas items? <ijchain> <emiliano> jancsika: no
From my own experiments on Debian:
- setting the tk scaling to 1, 0.2, 3, or 200 does not alter
a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes
- with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200
_will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size.
You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click <ctrl-n> for a new patch and it will look exactly right. Also try:
[label foo( | [vsl]
... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling.
Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont
Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at "1" may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets.
So-- is there any reason not to remove "tk scaling 1"?
Thanks, Jonathan
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
In general, removing bits of code willy-nilly is a bad idea. In this case, it took a ton of testing to get the right set of tweaks working across all platforms smoothly with the same pixel sizes on all platforms. Given that you only tested on GNU/Linux, its a really bad idea to propose changes based only on one platform unless you are planning to drop support for all other platforms.
So follow what the comment there says: "This guarantees that patches will be pixel-exact on every platform". If we had a pure Tcl/Tk GUI, then we could actually use tk scaling, and allow the user to adjust the tk scaling number, thereby having a zoomable interface. That will require removing all GUI logic from the pd core and putting it only in the GUI.
.hc
On 06/12/2013 07:54 PM, Miller Puckette wrote:
Hi Jonathan et a -
I've never understood the reason tk_scaling is touched in the TK code and unless someone else objects I'll try taking it out of the vanilla source.
thanks Miller
On Tue, Jun 11, 2013 at 06:11:57PM -0700, Jonathan Wilkes wrote:
Hi list,
From tcl/pd-gui: # we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform tk scaling 1
From #tcl on freenode: <jancsika> hello. does tk scaling affect canvas items? <ijchain> <emiliano> jancsika: no
From my own experiments on Debian:
- setting the tk scaling to 1, 0.2, 3, or 200 does not alter
a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes
- with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200
_will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size.
You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click <ctrl-n> for a new patch and it will look exactly right. Also try:
[label foo( | [vsl]
... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling.
Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont
Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at "1" may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets.
So-- is there any reason not to remove "tk scaling 1"?
Thanks, Jonathan
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
What I've never understood is this: why wouldn't it suffice to 'unscale' just the fonts Pd uses explicitly? One can get an unscaled font by asking for a size like -12 - then we wouldn't have to bash tk_scalaing globally (thereby ruining font sizes in open dialogs and whatnot that Pd doesn't depend on anyhow.)
(the relevant doc is in the "font" manual age for TK; "If size is a negative number, its absolute value is interpreted as a size in pixels."
cheers Miller
On Tue, Jun 18, 2013 at 01:39:30PM -0400, Hans-Christoph Steiner wrote:
In general, removing bits of code willy-nilly is a bad idea. In this case, it took a ton of testing to get the right set of tweaks working across all platforms smoothly with the same pixel sizes on all platforms. Given that you only tested on GNU/Linux, its a really bad idea to propose changes based only on one platform unless you are planning to drop support for all other platforms.
So follow what the comment there says: "This guarantees that patches will be pixel-exact on every platform". If we had a pure Tcl/Tk GUI, then we could actually use tk scaling, and allow the user to adjust the tk scaling number, thereby having a zoomable interface. That will require removing all GUI logic from the pd core and putting it only in the GUI.
.hc
On 06/12/2013 07:54 PM, Miller Puckette wrote:
Hi Jonathan et a -
I've never understood the reason tk_scaling is touched in the TK code and unless someone else objects I'll try taking it out of the vanilla source.
thanks Miller
On Tue, Jun 11, 2013 at 06:11:57PM -0700, Jonathan Wilkes wrote:
Hi list,
From tcl/pd-gui: # we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform tk scaling 1
From #tcl on freenode: <jancsika> hello. does tk scaling affect canvas items? <ijchain> <emiliano> jancsika: no
From my own experiments on Debian:
- setting the tk scaling to 1, 0.2, 3, or 200 does not alter
a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes
- with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200
_will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size.
You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click <ctrl-n> for a new patch and it will look exactly right. Also try:
[label foo( | [vsl]
... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling.
Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont
Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at "1" may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets.
So-- is there any reason not to remove "tk scaling 1"?
Thanks, Jonathan
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
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-dev@iem.at Sent: Tuesday, June 18, 2013 2:12 PM Subject: Re: [PD-dev] remove tk scaling
What I've never understood is this: why wouldn't it suffice to 'unscale'
just the fonts Pd uses explicitly? One can get an unscaled font by asking for a size like -12 - then we wouldn't have to bash tk_scalaing globally (thereby ruining font sizes in open dialogs and whatnot that Pd doesn't depend on anyhow.)
(the relevant doc is in the "font" manual age for TK; "If size is
a negative number, its absolute value is interpreted as a size in pixels."
That's exactly what Pd does-- I should have said in my previous message I tested patches with 0.44-3 on Debian Wheezy, OSX, and Windows XP. All the iemgui and object fonts must be negative because they are pixel exact whether you use [tk scaling 0.2] or [tk scaling 8].
Furthermore, if someone codes a gui external that doesn't use pixel sizes for fonts to appear on the canvas _and_ they want pixel-exactness, it's a bug, no?
-Jonathan
On 06/18/2013 06:21 PM, Jonathan Wilkes wrote:
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-dev@iem.at Sent: Tuesday, June 18, 2013 2:12 PM Subject: Re: [PD-dev] remove tk scaling
What I've never understood is this: why wouldn't it suffice to 'unscale'
just the fonts Pd uses explicitly? One can get an unscaled font by asking for a size like -12 - then we wouldn't have to bash tk_scalaing globally (thereby ruining font sizes in open dialogs and whatnot that Pd doesn't depend on anyhow.)
(the relevant doc is in the "font" manual age for TK; "If size is
a negative number, its absolute value is interpreted as a size in pixels."
That's exactly what Pd does-- I should have said in my previous message I tested patches with 0.44-3 on Debian Wheezy, OSX, and Windows XP. All the iemgui and object fonts must be negative because they are pixel exact whether you use [tk scaling 0.2] or [tk scaling 8].
Furthermore, if someone codes a gui external that doesn't use pixel sizes for fonts to appear on the canvas _and_ they want pixel-exactness, it's a bug, no?
-Jonathan
The situation is a big mess, no argument here. But you're not going to fix it by messing with [tk scaling], you'll just fix one issue, and others will pop up. I just see no reason to mess with that stuff until there is real change to the core, and the gui is completely separate from the core. Then we can actually do useful things, like a zoomable patch GUI.
Indeed, you're free to do whatever in vanilla, but in Pd-extended, I'll not include any such changes.
.hc
________________________________
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-dev@iem.at" pd-dev@iem.at Sent: Tuesday, June 18, 2013 8:55 PM Subject: Re: [PD-dev] remove tk scaling
On 06/18/2013 06:21 PM, Jonathan Wilkes wrote:
>From: Miller Puckette msp@ucsd.edu
To: Hans-Christoph Steiner hans@at.or.at Cc: pd-dev@iem.at Sent: Tuesday, June 18, 2013 2:12 PM Subject: Re: [PD-dev] remove tk scaling
[...]
(the relevant doc is in the "font" manual age for TK; "If size is
a negative number, its absolute value is interpreted as a size in pixels."
That's exactly what Pd does-- I should have said in my previous message I tested patches with 0.44-3 on Debian Wheezy, OSX, and Windows XP. All the iemgui and object fonts must be negative because they are pixel exact whether you use [tk scaling 0.2] or [tk scaling 8].
Furthermore, if someone codes a gui external that doesn't use pixel sizes for fonts to appear on the canvas _and_ they want pixel-exactness, it's a bug, no?
-Jonathan
The situation is a big mess, no argument here.
No, it's not. As I said, patches are currently pixel-exact across platforms, and they remain that way regardless of the value supplied to [tk scaling].
But you're not going to fix it by messing with [tk scaling], you'll just fix one issue, and others will pop up.
Can you give an example of one of those issues?
So far you have a single comment about pixel-exactness which is at the very least no longer relevant. (While there is a bug related to the default tk scaling value, it's in a different domain and has evidently been solved with a one-liner, without introducing the font problems I mentioned.)
-Jonathan
On 06/18/2013 10:35 PM, Jonathan Wilkes wrote:
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-dev@iem.at" pd-dev@iem.at Sent: Tuesday, June 18, 2013 8:55 PM Subject: Re: [PD-dev] remove tk scaling
On 06/18/2013 06:21 PM, Jonathan Wilkes wrote:
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-dev@iem.at Sent: Tuesday, June 18, 2013 2:12 PM Subject: Re: [PD-dev] remove tk scaling
[...]
(the relevant doc is in the "font" manual age for TK; "If size is
a negative number, its absolute value is interpreted as a size in pixels."
That's exactly what Pd does-- I should have said in my previous message I tested patches with 0.44-3 on Debian Wheezy, OSX, and Windows XP. All the iemgui and object fonts must be negative because they are pixel exact whether you use [tk scaling 0.2] or [tk scaling 8].
Furthermore, if someone codes a gui external that doesn't use pixel sizes for fonts to appear on the canvas _and_ they want pixel-exactness, it's a bug, no?
-Jonathan
The situation is a big mess, no argument here.
No, it's not. As I said, patches are currently pixel-exact across platforms, and they remain that way regardless of the value supplied to [tk scaling].
But you're not going to fix it by messing with [tk scaling], you'll just fix one issue, and others will pop up.
Can you give an example of one of those issues?
So far you have a single comment about pixel-exactness which is at the very least no longer relevant. (While there is a bug related to the default tk scaling value, it's in a different domain and has evidently been solved with a one-liner, without introducing the font problems I mentioned.)
-Jonathan
What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. Does anyone object to the idea of truly separating the GUI from the core? I haven't heard them.
.hc
[discussion of tk scaling deleted...]
What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. Does anyone object to the idea of truly separating the GUI from the core? I haven't heard them.
.hc
I already gained something... I can read the Pd console output now :)
Anyhow, if by separating the GUI from the core you mean re-writing the Pd patch editor in Tcl/TK, I think that would create enormous headaches. i enjoyed some of those with Max/FTS (in which the GUI layer was responsible for editing) and Pd's separation of duties is partly a reaction from that experience. But now there's even a stronger reason - since the GUI is now written in a scripting language it is likely to be very hard to get it to the level of robustness and performance needed in an editor.
But perhaps you mean something else, such as putting an abstract layer between Pd 'proper' and the Tcl/TK code. That might be feasible although I think it would still be quite a pain.
OTOH I recently talked with Peter Brinkmann about the idea of making an API for 'graphics updates' (changing float and table values) so that non-GUI-users could have an easier time seeing patch state. This seems a manageable first step...
cheers Miller
On 06/19/2013 04:38 PM, Miller Puckette wrote:
[discussion of tk scaling deleted...]
What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. Does anyone object to the idea of truly separating the GUI from the core? I haven't heard them.
.hc
I already gained something... I can read the Pd console output now :)
You can also just change the console font size with the font panel for temporary changes, or set the console font size if you want it permanent. If that's not in Pd-vanilla, feel free to take it from Pd-extended. tk scaling is not the way to set font sizes. Setting the font size is the way to do that.
Anyhow, if by separating the GUI from the core you mean re-writing the Pd patch editor in Tcl/TK, I think that would create enormous headaches. i enjoyed some of those with Max/FTS (in which the GUI layer was responsible for editing) and Pd's separation of duties is partly a reaction from that experience. But now there's even a stronger reason - since the GUI is now written in a scripting language it is likely to be very hard to get it to the level of robustness and performance needed in an editor.
But perhaps you mean something else, such as putting an abstract layer between Pd 'proper' and the Tcl/TK code. That might be feasible although I think it would still be quite a pain.
OTOH I recently talked with Peter Brinkmann about the idea of making an API for 'graphics updates' (changing float and table values) so that non-GUI-users could have an easier time seeing patch state. This seems a manageable first step...
cheers Miller
There are many python based GUIs that perform orders of magnitude better than Pd when it comes to screen drawing performance. Max/FTS was 20+ years ago, scripting languages have come a long way since then. The current situation guarantees crappy performance because it forces things to be implemented in a way that avoids graphics optimizations. In Pd's current architecture, things need to be handled incrementily and over a network socket. In any decent graphics programming environment, updates can be handled en masse.
.hc
________________________________ From: Hans-Christoph Steiner hans@at.or.at To: Miller Puckette msp@ucsd.edu Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-dev@iem.at" pd-dev@iem.at Sent: Wednesday, June 19, 2013 11:14 PM Subject: Re: [PD-dev] remove tk scaling
[...]
There are many python based GUIs that perform orders of magnitude better than
Pd when it comes to screen drawing performance. Max/FTS was 20+ years ago, scripting languages have come a long way since then. The current situation guarantees crappy performance because it forces things to be implemented in a way that avoids graphics optimizations. In Pd's current architecture, things need to be handled incrementily and over a network socket. In any decent graphics programming environment, updates can be handled en masse.
I'm curious what your plan is for making a clean separation between the core and the gui without breaking binary compatibility. Pd-l2ork, which unfortunately does break binary compatibility, does some gui updates en masse by leveraging canvas item tags to move the objects. If there's a way to do that and keep binary compatibility that would be great.
-Jonathan
.hc
Anyhow, if by separating the GUI from the core you mean re-writing the Pd patch editor in Tcl/TK, I think that would create enormous headaches. i enjoyed some of those with Max/FTS (in which the GUI layer was responsible for editing) and Pd's separation of duties is partly a reaction from that experience. But now there's even a stronger reason - since the GUI is now written in a scripting language it is likely to be very hard to get it to the level of robustness and performance needed in an editor.
But perhaps you mean something else, such as putting an abstract layer between Pd 'proper' and the Tcl/TK code. That might be feasible although I think it would still be quite a pain.
OTOH I recently talked with Peter Brinkmann about the idea of making an API for 'graphics updates' (changing float and table values) so that non-GUI-users could have an easier time seeing patch state. This seems a manageable first step...
cheers Miller
There are many python based GUIs that perform orders of magnitude better than Pd when it comes to screen drawing performance. Max/FTS was 20+ years ago, scripting languages have come a long way since then. The current situation guarantees crappy performance because it forces things to be implemented in a way that avoids graphics optimizations. In Pd's current architecture, things need to be handled incrementily and over a network socket. In any decent graphics programming environment, updates can be handled en masse.
.hc
I was trying to make 2 separate argments... First I think it's a miserable experience makeing an editor in one process for complex data structures that are needed by a different process (the experience I learned from Max/FTS). Second, even if one were to try it, I don't think any scripting language from 1993 or 2050 will be up to it. I could be wrong on the latter point but I'm pretty sure I'm right on the former.
I think we're converging on the concludion that 'th scaling 1' is appropriate for Pd extended (where taking the line out could break unknown hundreds of third-party objects/features/plug-ins) but inapprorpriate for vanilla where I still fail to see any problems from taking it out - although I've only tried it in a couple of environments so far.
cheers Miller
On 06/18/2013 10:35 PM, Jonathan Wilkes wrote:
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-dev@iem.at" pd-dev@iem.at Sent: Tuesday, June 18, 2013 8:55 PM Subject: Re: [PD-dev] remove tk scaling
On 06/18/2013 06:21 PM, Jonathan Wilkes wrote:
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-dev@iem.at Sent: Tuesday, June 18, 2013 2:12 PM Subject: Re: [PD-dev] remove tk scaling
[...]
(the relevant doc is in the "font" manual age for TK; "If size is
a negative number, its absolute value is interpreted as a size in pixels."
That's exactly what Pd does-- I should have said in my previous message I tested patches with 0.44-3 on Debian Wheezy, OSX, and Windows XP. All the iemgui and object fonts must be negative because they are pixel exact whether you use [tk scaling 0.2] or [tk scaling 8].
Furthermore, if someone codes a gui external that doesn't use pixel sizes for fonts to appear on the canvas _and_ they want pixel-exactness, it's a bug, no?
-Jonathan
The situation is a big mess, no argument here.
No, it's not. As I said, patches are currently pixel-exact across platforms, and they remain that way regardless of the value supplied to [tk scaling].
But you're not going to fix it by messing with [tk scaling], you'll just fix one issue, and others will pop up.
Can you give an example of one of those issues?
So far you have a single comment about pixel-exactness which is at the very least no longer relevant. (While there is a bug related to the default tk scaling value, it's in a different domain and has evidently been solved with a one-liner, without introducing the font problems I mentioned.)
-Jonathan
What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. Does anyone object to the idea of truly separating the GUI from the core? I haven't heard them.
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-19 22:06, Hans-Christoph Steiner wrote:
What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes.
i think the biggest gain would be to not have to discuss this over and over. which i think would be a big improvement.
if the function of the code was obvious, we wouldn't have to discuss it either.
fgamsdr IOhannes
________________________________
From: Hans-Christoph Steiner hans@at.or.at To: pd-dev@iem.at Sent: Tuesday, June 18, 2013 1:39 PM Subject: Re: [PD-dev] remove tk scaling
In general, removing bits of code willy-nilly is a bad idea.
Agreed. Now let's talk about this specific case.
In this case, it took a ton of testing to get the right set of tweaks working across all platforms smoothly with the same pixel sizes on all platforms.
And those tweaks (read: using pixel font sizes) give pixel exact results across OSX, Windows, and Debian, _regardless_ of what value is set for tk scaling.
[tk scaling 1] is what leads to the tiny font problem on Windows.
Given that you only tested on GNU/Linux, its a really bad idea to propose changes based only on one platform unless you are planning to drop support for all other platforms.
Sorry: I tested patch pixel-exactness on all platforms and only the canvas demo below in Debian. [tk scaling] for "point-sized" fonts (i.e., non-negative values) in Windows will affect canvas text items, but not "pixel-sized" text items, which AFAICT is everything in Pd.
I've tested with a) long comments, b) iemguis and their labels, and c) normal object and message boxes. All the above are pixel-exact across OSX, Windows, GNU/Linux regardless of tk scaling value.
So follow what the comment there says: "This guarantees that patches will be pixel-exact on every platform". If we had a pure Tcl/Tk GUI, then we could actually use tk scaling, and allow the user to adjust the tk scaling number, thereby having a zoomable interface. That will require removing all GUI logic from the pd core and putting it only in the GUI.
As I pointed out below, "point-sized" fonts (i.e., non-negative) aren't affected by [tk scaling n] on Debian (X11), so using [tk scaling n] to get a zoomable interface is not cross-platform and therefore isn't a possibility.
Also, note that the starting point for this was the tiny font bug that reappears every time someone makes a gui-plugin or new dialog with a widget that didn't get caught by one of the many [option add etc.] statements that are there to correct the bug caused by [tk scaling 1].
-Jonathan
.hc
On 06/12/2013 07:54 PM, Miller Puckette wrote:
Hi Jonathan et a -
I've never understood the reason tk_scaling is touched in the TK code and unless someone else objects I'll try taking it out of the vanilla source.
thanks Miller
On Tue, Jun 11, 2013 at 06:11:57PM -0700, Jonathan Wilkes wrote:
Hi list,
From tcl/pd-gui:
# we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform tk scaling 1
From #tcl on freenode: <jancsika> hello. does tk scaling affect canvas items? <ijchain> <emiliano> jancsika: no
From my own experiments on Debian:
- setting the tk scaling to 1, 0.2, 3, or 200 does not alter
a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes
- with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200
_will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size.
You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click <ctrl-n> for a new patch and it will look exactly right. Also try:
[label foo( | [vsl]
... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling.
Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont
Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at "1" may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets.
So-- is there any reason not to remove "tk scaling 1"?
Thanks, Jonathan
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
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-18 19:39, Hans-Christoph Steiner wrote:
In general, removing bits of code willy-nilly is a bad idea.
sure.
In this case, So follow what the comment there says: "This guarantees that patches will be pixel-exact on every platform".
this obviously hints at some underlying problem. still it would be great to have more references in the comments, e.g. "without this, objectbox sizes will be off by one on *BSD platforms, cf. http://bugs.puredata.info/42 and http://wiki.tcl.tk/666)"
the vc-log doesn't reveal a lot here (the line in question has been added in commitish b23a763e "import new tcl code from devel" :-() the situation has become a bit better, now that "3rd party contributions" (anybody but miller) use git for smaller commits.
in any case, i strongly suggest that each non-obvious addition to the code should be backed up by evidence. "this is time-proven code that guarantees the same behaviour on all platforms, and your addition has not been tested" is a bit of a show-stopper wehn it comes to new development.
nevertheless, here is some discussion that backs up *not* removing the line: http://lists.puredata.info/pipermail/pd-list/2007-11/056834.html
ghsmdf IOhannes
________________________________ From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Sent: Wednesday, June 19, 2013 3:42 AM Subject: Re: [PD-dev] remove tk scaling
[...]
nevertheless, here is some discussion that backs up *not* removing the
line: http://lists.puredata.info/pipermail/pd-list/2007-11/056834.html
As usual matju's comment is spot on in that thread, and since ttk widgets themselves use point sizes then [tk scaling 1] can and does cause the tiny fonts on Windows.
Also, have a look at the following: From g_mycanvas.c in 0.41 -font {{%s} %d %s}
From g_mycanvas.c in 0.43: -font {{%s} -%d %s}
That is why I see pixel exact patches across OSX, WinXP and Debian with Pd >= 0.43, regardless of n for [tk scaling n], and why Cyrille saw different font sizes. The negative font size is what guarantees pixel exact patches, not tk scaling.
This leaves us with Cyrille's report about the "the font size of text in the main pd window" changing. The link to the screenshot he posted is dead, but as long as the font size isn't abnormally sized compared to other applications I don't see why that would be a problem. The whole point of modern geometry managers is to adjust to whatever size is needed to accomodate the widgets and fonts associated with them. If Pd requires pixel-exact windows and dialogs for the gui stuff that isn't a pixel-exact dataflow diagram (read: all the stuff that isn't a patch) then we're doing something wrong.
-Jonathan
ghsmdf IOhannes
I looked and every font specification I could find in Pd vanilla has its size specified as negative. So I'm of the belief that taking the "tk scaling 1" out will have NO EFFECT on the sizes of drawn text on canvases in vanilla.
Only gotchas I can imagine are: (1) maybe there's something else besides text fonts that are specified in points and could break; or (2) some extern in Pd extended is drawing texts on canvases, or (3) there's something in Pd extended that depends on exact font sizes that isn't inside a Pd canvas.
It's clear that we can't leave tk scaling bashed to 1 forever - it's messing stuff up for people with high-res displays. So I'm for biting the bullet, taking it out, and seeing if anything that breaks can't be fixed locally.
cheers Miller
On Wed, Jun 19, 2013 at 11:38:41AM -0700, Jonathan Wilkes wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Sent: Wednesday, June 19, 2013 3:42 AM Subject: Re: [PD-dev] remove tk scaling
[...]
nevertheless, here is some discussion that backs up *not* removing the
line: http://lists.puredata.info/pipermail/pd-list/2007-11/056834.html
As usual matju's comment is spot on in that thread, and since ttk widgets themselves use point sizes then [tk scaling 1] can and does cause the tiny fonts on Windows.
Also, have a look at the following: From g_mycanvas.c in 0.41 -font {{%s} %d %s}
From g_mycanvas.c in 0.43: -font {{%s} -%d %s}
That is why I see pixel exact patches across OSX, WinXP and Debian with Pd >= 0.43, regardless of n for [tk scaling n], and why Cyrille saw different font sizes. The negative font size is what guarantees pixel exact patches, not tk scaling.
This leaves us with Cyrille's report about the "the font size of text in the main pd window" changing. The link to the screenshot he posted is dead, but as long as the font size isn't abnormally sized compared to other applications I don't see why that would be a problem. The whole point of modern geometry managers is to adjust to whatever size is needed to accomodate the widgets and fonts associated with them. If Pd requires pixel-exact windows and dialogs for the gui stuff that isn't a pixel-exact dataflow diagram (read: all the stuff that isn't a patch) then we're doing something wrong.
-Jonathan
ghsmdf IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
Miller Puckette