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
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
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
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.
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
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
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
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
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
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'
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
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
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:
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
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
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
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
17 matches
Mail list logo
