cheers miller, that would be awesome.
sorry to keep this going, but what about bug #2:
2) The opening position of property dialogs, when repeatedly accessed,
wander down the screen, until eventually, they are nearly off the
bottom of the screen. I'm guessing the behavior is partly intentional,
Looks like that's purely TK trying to help... ugh.
cheers
Miller
On Mon, Mar 05, 2007 at 07:15:48PM +0900, hard off wrote:
cheers miller, that would be awesome.
sorry to keep this going, but what about bug #2:
2) The opening position of property dialogs, when repeatedly accessed,
wander
The growth seems to come from TK... I added a correction (g_canvas.c,
line 1051) but it looks like I'd better go adjust it again...
cheers
Miller
On Mon, Feb 26, 2007 at 05:43:41PM -0500, [EMAIL PROTECTED] wrote:
Roman Haefeli wrote:
On Mon, 2007-02-26 at 22:34 +0100, Derek Holzer wrote:
the worst is when you have a bunch of subpatches that you don't need
to edit or look at after you do the initial coding.
..if you save your main patch 40 or 50 times, those 3 or 4 pixels
really add up, and all your subpatches grow really huge.
___
On 2/27/07, Steffen [EMAIL PROTECTED] wrote:
2) that a patch canvas can be bigger then the screen size
since a solution to the one might not be a solution to the other.
As for the second. We have different screens with different
resolutions and size. So what can fit on one screen might not
Hallo,
Steffen hat gesagt: // Steffen wrote:
I don't suppose I'm wrong by stating that linux users have the same
problem, but just have better control over the window system such
that resizing the windows is an easy job.
I don't know about Apple, but you can run Blackbox on Windows
this came up not so long ago: just change the canvas sizes in a text editor.
cheers, robbert
Chuckk Hubbard [EMAIL PROTECTED] wrote:
The reason it was a huge problem on Mac was that, once the
window is larger than your display, there's no way to get to the
resize button on the lower right
You lost me at just. That you can fix it by opening a patch in a
text editor, finding and adjusting all the affected windows, saving
the file, and reopening it in Pd doesn't mean it's not a bug!
-Chuckk
On 2/26/07, robbert van hulzen [EMAIL PROTECTED] wrote:
this came up not so long ago: just
I'd point more to OS X or the Aqua desktop as the culprit, actually.
Don't know 'bout windows, but on many Linux window managers, you can use
the Alt+Mouse to relocate a window (of any app) and find the resize tab
at the edges. File a feature request at Apple, where they get paid to
read those
You can also just try changing your screen resolution if possible, to
see if the out-of-bounds edges of the PD window show up.
d.
Chuckk Hubbard wrote:
You lost me at just. That you can fix it by opening a patch in a
text editor, finding and adjusting all the affected windows, saving
the
Roman Haefeli wrote:
subtract 3px
on my system it's 4 pix. osx 10.4.8. tcl 8.4.
m.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Sorry for my swift previous answer on this thread. I didn't know that
there was an actual bug involved, instead of just differences in how
OSes handle oversize windows.
d.
marius schebella wrote:
Roman Haefeli wrote:
subtract 3px
on my system it's 4 pix. osx 10.4.8. tcl 8.4.
m.
--
oops, sorry about the number, i didn't want to say, it's exact 3px. i
just estimated. i am working actually on linux, so i couldn't test.
though, it would be interesting to see, if it's also 4px on windows.
roman
On Mon, 2007-02-26 at 17:40 -0500, marius schebella wrote:
Roman Haefeli wrote:
Yup.
On 2/26/07, Roman Haefeli [EMAIL PROTECTED] wrote:
oops, sorry about the number, i didn't want to say, it's exact 3px. i
just estimated. i am working actually on linux, so i couldn't test.
though, it would be interesting to see, if it's also 4px on windows.
roman
On Mon, 2007-02-26
when I posted that bug first time (in 2002) it was 2 pixels on windows
AND on linux(!).
marius.
Chuckk Hubbard wrote:
Yup.
On 2/26/07, Roman Haefeli [EMAIL PROTECTED] wrote:
oops, sorry about the number, i didn't want to say, it's exact 3px. i
just estimated. i am working actually on
Try Duplicate, Ctl-D. The new copy is offset slightly right and down.
Thanks I'll try that!
Steve
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
I noticed 1) before too, on Mac. I'm not sure if the same thing has
happened to me on Windows; resizing windows is much much easier in
Windows. The reason it was a huge problem on Mac was that, once the
window is larger than your display, there's no way to get to the
resize button on the lower
On Fri Feb 23, 2007 at 07:42:07AM +0100, Frank Barknecht wrote:
Hallo,
marius schebella hat gesagt: // marius schebella wrote:
no, that is a known problem which also appears under windows. but maybe
not under linux.
I've never encountered problem 1), the resizing, on my Linux machines.
3) When you copy and paste (Ctrl-C, Ctrl-V in immediate succession), the
pasted object is in exactly the same position as the copied object (fine),
except that it is _underneath_, so when you click and drag it out of the way
you move the original instead, messing up your carefully placed patch
On 23/02/2007, at 2:12 PM, Stephen Sinclair wrote:
3) When you copy and paste (Ctrl-C, Ctrl-V in immediate
succession), the pasted object is in exactly the same position as
the copied object (fine), except that it is _underneath_, so when
you click and drag it out of the way you move
Hallo,
Stephen Sinclair hat gesagt: // Stephen Sinclair wrote:
3) When you copy and paste (Ctrl-C, Ctrl-V in immediate succession), the
pasted object is in exactly the same position as the copied object (fine),
except that it is _underneath_, so when you click and drag it out of the way
you
Hello all,
There are two minor issues in PD that I've ignored for a long time, but
they do tend to become annoying after long editing sessions. (The fact
that I'm complaining about such small things attests to how amazing PD
is otherwise.)
1) Windows do not hold their size. If I carefully
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
2) The opening position of property dialogs, when repeatedly accessed,
wander down the screen, until eventually, they are nearly off the
bottom of the screen. I'm guessing the behavior is partly intentional,
to enable tiling of
no, that is a known problem which also appears under windows. but maybe
not under linux.
every time you save the patch, the size gets increased by 1 or even 2
pixels... I think it is a tcl/tk problem.
marius.
Frank Barknecht wrote:
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
2) The
both problems appear on mac too. probably tcl/tk related too, i think.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Frank Barknecht wrote:
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
2) The opening position of property dialogs, when repeatedly accessed,
wander down the screen, until eventually, they are nearly off the
bottom of the screen. I'm guessing the behavior is partly intentional,
Aha! The window is consistently growing by a few pixels, that's why I
wouldn't notice it until some random time! Thanks for clearing that up.
I couldn't find anything about this on a quick search of Tcl/Tk known
issues, but it does seem like a likely source of the problem.
Phil
marius
Hallo,
marius schebella hat gesagt: // marius schebella wrote:
no, that is a known problem which also appears under windows. but maybe
not under linux.
I've never encountered problem 1), the resizing, on my Linux machines.
Ciao
--
Frank Barknecht _ __footils.org_
28 matches
Mail list logo
