[PD-dev] [ pure-data-Patches-2947822 ] space character in gui labels causes disaster
Patches item #2947822, was opened at 2010-02-08 05:12 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=2947822group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Miller Puckette (millerpuckette) Summary: space character in gui labels causes disaster Initial Comment: Steps to reproduce: 1 - Open the attached patch Note the size of the radio and toggle. Note also they have send symbols set to xxx and yyy respectively 2 - Click on the big bang at the top This composes a symbol containing space characters and sends it as a label to both the radio and the toggle. This seems to work: the label is actually set with spaces, and the radio and toggle still work. However, if you right-click on any of them and try to select properties, the properties dialog won't open 3 - Now save the patch and close it 4 - Open the patch again. The radio and toggle properties have been completely reset: their size have been reset to default, and also the number property of the radio. They have lost their send symbol too: you can see the outlet and if you use them, the r objects won't receive anything. However, if you open the properties dialog of the radio or toggle, you'll see that the send property is still there (not the same can be said for the size and number); if you now do Apply or Ok, the send symbol will be restored. So, spaces in the label of a gui object cause weirdnesses and potential disaster. Note that data is lost (the properties of the gui objects) if the patch is saved after assigning such a label, and i is lost silently with no error message at any moment. There are ather forbidden characters ithat don't behave properly n labels, such as the open square bracket [ (as reported in another bug report). However the space character is more disatrous as it causes data loss. Object should either accept ALL characters for a label, or properly detect and refuse forbidden characters, which should be documented, avoiding unexpected consequences. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2013-02-01 08:19 Message: I applied IOhannes' patch #0002 to Pd-extended 0.44.0 -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-04 11:31 Message: Patch #0001 should be applied regardless. Its a simple fix that also address having characters like [ ] in labels. As for patch #0002 , the iemguis also replace spaces with _ when you enter the name in the Properies panel. Symbols can have spaces, and you can set the label with a [label symbol( message, so as IOhannes pointed out, the missing piece of the puzzle is saving properly. Since patch #0002 makes Pd write out the file format that is already supported, I think it would be good to include it. Then strnescape() will also have to change when we implement proper escaping support throughout Pd. Unless you have plans to implement that in 0.44, I think its definitely worth including incremental solutions like patch #0002 -- Comment By: Miller Puckette (millerpuckette) Date: 2012-12-03 19:27 Message: Note the much simpler way the number box finesses this problem. I'm scared of adding code to m_binbuf.c to escape spaces (what will happen when we later allow backslashes into the mix?). But without the binbuf patch the fix to the IEM guis doesn't work - so I'm tempted for now just to do as in the number box - it's not incompatible to do it right at some ater date when we can thonk the whole thing through (it's all over the Pd code and all needs to be figured out together). -- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-13 16:45 Message: added another patch (0002_*) that implements escaping spaces and tabs when saving the files to disk. i guess both patches should be applied for full fun. -- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-13 15:36 Message: the bug.pd file does not correctly show the labels with blanks after reloading but it doesn't throw any warnings) however, the bugfix-patch doesn't work for me. nevertheless the problem is known and is not in the pd-gui communication, but rather in the way the label is stored on disk (and then interpreted on reload): afaict, blanks (and other special chars) really must be escaped with backslash (e.g. A\ A\ A) when saved to disk
[PD-dev] [ pure-data-Patches-3101526 ] Width parameter in properties for atom symbol boxes broken
Patches item #3101526, was opened at 2010-11-02 04:38 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3101526group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jwif () Assigned to: Miller Puckette (millerpuckette) Summary: Width parameter in properties for atom symbol boxes broken Initial Comment: *From testing this seems to apply only to symbol and atom boxes with the 'Width' parameter at the center top* Choosing Properties from the right-click context menu for these gui objects brings up the properties window with the Width parameter selected and a cursor inside. However I cannot delete the default value using backspace without either moving the cursor arrow left or highlighting it with the mouse. Any other key works aside from backspace. Also all other gui properties boxes highlight the default value aside from these two (could be related?). Pd version 0.43-0test3 Macbook Pro running OS X 10.6.4/Intel built-in sound -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-01-26 19:52 Message: fixed with attached patch (at least on Ubuntu/oneiric) -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-11-07 17:28 Message: I could not reproduce this using the head of 0.43 git running on Mac OS X 10.5.8 using both Tcl/Tk 8.4.19 and 8.5.8. I wonder if its a 10.6 issue? Can you give detailed instructions on how to make it happen and an example patch? Perhaps a screenshot to illustrate the last point. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3101526group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-2893947 ] audio doesn't reconnect after sleep on Mac OS X
Patches item #2893947, was opened at 2009-11-07 13:23 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=2893947group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: audio doesn't reconnect after sleep on Mac OS X Initial Comment: If you have Pd open on Mac OS X, and the computer goes to sleep, Pd looses connection to the audio, and you either need to restart or select the audio API again in order to get sound. Mac OS X can send sleep/wake events, so Pd should register to get these, and use them to reconnect to the audio when the machine wakes up. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-08-16 20:42 Message: any comment on why this was closed? -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-05-17 15:46 Message: Turns out it was easier and more effective to disable the 'audio stuck' code, which was done in Pd-extended 0.42.5: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revsortby=daterevision=13483 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=2893947group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] no more 'patch_series' branch for pd-extended.git
I've decided to stop using the 'patch_series' branch in the pd-extended.git and switch to a straightforward 'master' branch as the place where everything happens. The 'patch_series' branch worked well when Pd-extended was a set of patches against Pd-vanilla, but that is less and less the case. For example, there is no 'extra' objects in Pd-extended, instead that is treated as the 'extra' library which is in pure-data SVN. Its just a straight copy of the pd-vanilla extra objects with a build system like the library template. As Jonathan continues to work on his versions of the doc/2.control.examples, doc/3.audio.examples, etc. those will be removed from pd-extended.git and Pd-extended will use Jonathan's versions. Once I get a workable system for making a complete 'vanilla' library, then that stuff will be removed from pd-extended.git So in summary, it means that Pd-extended will track the core of Pd-vanilla within git, but the objects, extra, doc, etc. will be spun out to be tracked separately. I think that'll greatly smooth out the development process. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Not a PD bug [Re: Pd-dev Digest, Vol 94, Issue 33]
As regards my posting below, (GEM fails on Win Server...), I discovered it is a bug in Windows, not in GEM. Apparently, none of my window-mode OpenGL applications work. I have read that it is because I don't use the Aero desktop theme. I tried enabling the Theme service, and selecting an Aero desktop theme, and IT WORKED. I am going to ask about this on Microsoft forums. Very weird. I think it only applies to 64-bit Windows (maybe something to do with WoW subsystem?) Fra: pd-dev-requ...@iem.at pd-dev-requ...@iem.at Til: pd-dev@iem.at Sendt: Onsdag, 30. januar 2013 12.00 Emne: Pd-dev Digest, Vol 94, Issue 33 Send Pd-dev mailing list submissions to pd-dev@iem.at To subscribe or unsubscribe via the World Wide Web, visit http://lists.puredata.info/listinfo/pd-dev or, via email, send a message with subject or body 'help' to pd-dev-requ...@iem.at You can reach the person managing the list at pd-dev-ow...@iem.at When replying, please edit your Subject line so it is more specific than Re: Contents of Pd-dev digest... Today's Topics: 1. GEM fails on Win Server 2008 R2 (Rastko) 2. [ pure-data-Bugs-3602601 ] search does not work (SourceForge.net) -- Message: 1 Date: Tue, 29 Jan 2013 13:22:56 + (GMT) From: Rastko dj_stk...@yahoo.co.uk Subject: [PD-dev] GEM fails on Win Server 2008 R2 To: pd-dev@iem.at pd-dev@iem.at Message-ID: 1359465776.62695.yahoomail...@web28801.mail.ir2.yahoo.com Content-Type: text/plain; charset=iso-8859-1 Hi, I am trying to get multimedia programs working on Windows Server 2008 R2. PD seems to be working, but GEM rendering doesn't. GEM starts fine, and there are no red messages. The rendering window (GEM window) is blank (doesn't get repainted).? pd.exe -verbose doesn't give info, but pd -verbose says it can't find 'gem.conf''. So, there are two different configurations? Because it also looses soundcard config. I would really like to make GEM work... Thanks -- next part -- An HTML attachment was scrubbed... URL: http://lists.puredata.info/pipermail/pd-dev/attachments/20130129/46dd00b9/attachment.html -- Message: 2 Date: Tue, 29 Jan 2013 17:18:47 -0800 From: SourceForge.net nore...@sourceforge.net Subject: [PD-dev] [ pure-data-Bugs-3602601 ] search does not work To: SourceForge.net nore...@sourceforge.net Message-ID: mailman.2.1359543601.1309.pd-...@iem.at Content-Type: text/plain; charset=UTF-8 Bugs item #3602601, was opened at 2013-01-29 17:18 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3602601group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: search does not work Initial Comment: The Search inside Help tab still does not work -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3602601group_id=55736 -- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev End of Pd-dev Digest, Vol 94, Issue 33 **___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] small regression regarding window placement
Hi Miller The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change: -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top (0 44 from the pd file gets overwritten by 0 50). I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it? Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
Drat.. On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. M On Fri, Feb 01, 2013 at 08:00:47PM +0100, Roman Haefeli wrote: Hi Miller The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change: -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top (0 44 from the pd file gets overwritten by 0 50). I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it? Roman ___ 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] small regression regarding window placement
This is sorted out in Pd-extended, if you want to compare. I'm not sure what the exact changes are. I think there is platform-specific logic to bump the window down if its in the menu bar. .hc On 02/01/2013 02:05 PM, Miller Puckette wrote: Drat.. On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. M On Fri, Feb 01, 2013 at 08:00:47PM +0100, Roman Haefeli wrote: Hi Miller The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change: -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top (0 44 from the pd file gets overwritten by 0 50). I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it? Roman ___ 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] small regression regarding window placement
On Fre, 2013-02-01 at 11:05 -0800, Miller Puckette wrote: On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. I should have given more context: #ifdef __APPLE__ #define GLIST_DEFCANVASYLOC 22 #else -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 #endif So it seems that particular change does not affect Mac OS X. Thus I assume that reverting it wouldn't change the behavior on Macs either. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. Sorry for not being of any help here. Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
On Fre, 2013-02-01 at 14:46 -0500, Hans-Christoph Steiner wrote: This is sorted out in Pd-extended, if you want to compare. I'm not sure what the exact changes are. I think there is platform-specific logic to bump the window down if its in the menu bar. In Pd-extended it is still set to '0' for non-Mac systems. Roman On 02/01/2013 02:05 PM, Miller Puckette wrote: Drat.. On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. M On Fri, Feb 01, 2013 at 08:00:47PM +0100, Roman Haefeli wrote: Hi Miller The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change: -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top (0 44 from the pd file gets overwritten by 0 50). I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it? Roman ___ 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] small regression regarding window placement
Found it... firther down in g_canvas.c: if (yloc GLIST_DEFCANVASYLOC) yloc = GLIST_DEFCANVASYLOC; if (xloc 0) xloc = 0; I'm not sure what the correct foolproofing should be (or indeed if it's a good idea to have foolproofing there at all). But anyhow removing those lines will make it possible for patches to restore themselves wherever they were saved from. cheers Miller On Fri, Feb 01, 2013 at 09:10:23PM +0100, Roman Haefeli wrote: On Fre, 2013-02-01 at 11:05 -0800, Miller Puckette wrote: On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. I should have given more context: #ifdef __APPLE__ #define GLIST_DEFCANVASYLOC 22 #else -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 #endif So it seems that particular change does not affect Mac OS X. Thus I assume that reverting it wouldn't change the behavior on Macs either. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. Sorry for not being of any help here. Roman ___ 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] small regression regarding window placement
I say remove that bit entirely and let the GUI handle figuring out where the window should go. Pd should just relay the unadulterated values from the Pd patch. Only the GUI can figure this out, especially considering all of the variations of window managers and platforms. These days Tk will handle a lot of this stuff for you. .hc On 02/01/2013 03:50 PM, Miller Puckette wrote: Found it... firther down in g_canvas.c: if (yloc GLIST_DEFCANVASYLOC) yloc = GLIST_DEFCANVASYLOC; if (xloc 0) xloc = 0; I'm not sure what the correct foolproofing should be (or indeed if it's a good idea to have foolproofing there at all). But anyhow removing those lines will make it possible for patches to restore themselves wherever they were saved from. cheers Miller On Fri, Feb 01, 2013 at 09:10:23PM +0100, Roman Haefeli wrote: On Fre, 2013-02-01 at 11:05 -0800, Miller Puckette wrote: On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. I should have given more context: #ifdef __APPLE__ #define GLIST_DEFCANVASYLOC 22 #else -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 #endif So it seems that particular change does not affect Mac OS X. Thus I assume that reverting it wouldn't change the behavior on Macs either. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. Sorry for not being of any help here. Roman ___ 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] More canvas position woes
Hi all The assumed window border sizes are hard-coded in tcl/pd-gui.tcl: set ::windowframex 3 set ::windowframey 53 However, those values might not be correct on some systems. On my system (with fluxbox as a window manager) those values actually are 0 and 44. This leads to moving canvas: Whenever I save a patch, close and open it again, it shifts 9px up and 3px to the left. This shift even happens on each 'vis 0, vis 1' cycle sent to [s pd-canvasname]. This is actually not a Pd question: Is there a way to know the actual windowframe sizes in tcl/tk? Detecting the actual sizes would be the only real solution to this problem, I suppose. Alternatively, is there a way to write a GUI plugin to put my adjustments into, so that I don't have to modify tcl/pd-gui.tcl after every Pd update? I - naively - tried to simply put this: set ::windowframex 0 set ::windowframey 44 into ~/pd-externals/correct_windowframe-plugin.tcl. It seems to work so far, if I load patches from the file-open menu. When loading a patch from the command line, the wrong values still are used for the main patch. For all sub-sequent canvases (a.k.a subpatches of the main patch, abstractions of the main patch or sub-sequently opened patches), the correct values from the plugin are taken. Another issue is the wrapping of the menu in narrow canvases. When I work in a patch that shows the menu in two lines, the offset increases by another 28px. This means that on each save/reload cycle (or 'vis 0, vis 1' cycle, for that matter) the canvas shifts up by 28px. Of course, it's not a really urgent problem, but still slightly annoying. Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Not a PD bug [Re: Pd-dev Digest, Vol 94, Issue 33]
On 02/01/2013 05:43 PM, Rastko wrote: As regards my posting below, (GEM fails on Win Server...), I discovered it is a bug in Windows, not in GEM. Apparently, none of my window-mode OpenGL applications work. I have read that it is because I don't use the Aero desktop theme. I tried enabling the Theme service, and selecting an Aero desktop theme, and IT WORKED. thanks. that is very valuable information. fafr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
On 02/01/2013 10:10 PM, Hans-Christoph Steiner wrote: I say remove that bit entirely and let the GUI handle figuring out where the window should go. yes! fgadm IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] More canvas position woes
For more on this topic, check out the comments in pdtk_canvas.tcl and this link: http://wiki.tcl.tk/11502 Tk X11 returns the size of the window without the framing, and the framing varies widely depending on the WM. For your plugin, you'll want to override pdtk_canvas_place_window using 'rename' and write one that works for your WM. .hc On 02/01/2013 05:34 PM, Roman Haefeli wrote: Hi all The assumed window border sizes are hard-coded in tcl/pd-gui.tcl: set ::windowframex 3 set ::windowframey 53 However, those values might not be correct on some systems. On my system (with fluxbox as a window manager) those values actually are 0 and 44. This leads to moving canvas: Whenever I save a patch, close and open it again, it shifts 9px up and 3px to the left. This shift even happens on each 'vis 0, vis 1' cycle sent to [s pd-canvasname]. This is actually not a Pd question: Is there a way to know the actual windowframe sizes in tcl/tk? Detecting the actual sizes would be the only real solution to this problem, I suppose. Alternatively, is there a way to write a GUI plugin to put my adjustments into, so that I don't have to modify tcl/pd-gui.tcl after every Pd update? I - naively - tried to simply put this: set ::windowframex 0 set ::windowframey 44 into ~/pd-externals/correct_windowframe-plugin.tcl. It seems to work so far, if I load patches from the file-open menu. When loading a patch from the command line, the wrong values still are used for the main patch. For all sub-sequent canvases (a.k.a subpatches of the main patch, abstractions of the main patch or sub-sequently opened patches), the correct values from the plugin are taken. Another issue is the wrapping of the menu in narrow canvases. When I work in a patch that shows the menu in two lines, the offset increases by another 28px. This means that on each save/reload cycle (or 'vis 0, vis 1' cycle, for that matter) the canvas shifts up by 28px. Of course, it's not a really urgent problem, but still slightly annoying. Roman ___ 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] [ pure-data-Patches-3602226 ] apply button is missing yet
Patches item #3602226, was opened at 2013-01-26 10:45 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3602226group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: lowtechism (lowtechism) Assigned to: Miller Puckette (millerpuckette) Summary: apply button is missing yet Initial Comment: It was discussed in Pd-list but apply button is not recovered yet. http://www.mail-archive.com/pd-list@iem.at/msg51331.html http://www.mail-archive.com/pd-list@iem.at/msg49361.html Pd version 0.43.4-extended Mac OS X 10.8.2 /Intel built-in sound -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2013-02-01 19:51 Message: fixed in pd-extended, tomorrow's build, and the patch is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3602226group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
