Re: [PD-dev] remove tk scaling
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHCp3EACgkQkX2Xpv6ydvT/XwCfenPQ1cxBPIrqH/mp7B+AptwY OXEAnRElcQcUcZrOUhx1dvXa4XW1dHFm =8T3/ -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHBYMoACgkQkX2Xpv6ydvRb7wCg2GyOFll5FGdvg9U59l3hTvvh ZzoAn2zxVoaLrmzfsUflZAPhCqbwbxg8 =sdfC -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
From: IOhannes m zmoelnig zmoel...@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
Re: [PD-dev] remove tk scaling
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 zmoel...@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
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
On 06/18/2013 10:35 PM, Jonathan Wilkes wrote: From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@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 m...@ucsd.edu To: Hans-Christoph Steiner h...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
On 06/18/2013 10:35 PM, Jonathan Wilkes wrote: From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@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 m...@ucsd.edu To: Hans-Christoph Steiner h...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
[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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
From: Hans-Christoph Steiner h...@at.or.at To: Miller Puckette m...@ucsd.edu Cc: Jonathan Wilkes jancs...@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___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
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
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. 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
From: Hans-Christoph Steiner h...@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
Re: [PD-dev] remove tk scaling
From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
On 06/18/2013 06:21 PM, Jonathan Wilkes wrote: From: Miller Puckette m...@ucsd.edu To: Hans-Christoph Steiner h...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@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 m...@ucsd.edu To: Hans-Christoph Steiner h...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
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
