[PD] Report on Pd-0.43.0-devel-windowsxp-i386.exe on windows xp
Hans-Christoph Steiner
hans at at.or.at
Wed Oct 14 19:30:36 CEST 2009
On Oct 14, 2009, at 8:31 AM, João Pais wrote:
> Hi,
>
> I installed the version on the title, and started doing some work
> with it.
> Here is a list of issues, big and small, as I go along:
>
>
> - lots of extra calls in the console while doing normal actions (new
> file,
> etc. etc.). won't list them all, I guess it might be a debugging
> thing.
yes, debug messages...
> - alt-[key] doesn't work on menus? alt-f should make file menu open
Does that work on other versions of Pd?
> - path+startup windows with too small font size
> - text editor doesn't work, is he already gone? data properties'
> editor
> works.
It just needs to be implemented. Any volunteers? I've never used it
so I don't know what its supposed to do. Or really, the better
approach IMHO is to make the in-place editing good enough so you don't
need the Text Editor.
> - don't know what popup mode is and saw no obvious difference - but I
> didn't bother to look for it as well
Popup mode means the Pd window will popup to the front if any message
is printed there. I think I'll move that to a plugin.
> - nice new design for the windows
>
> - in the past I asked for pd to save window position also when
> windows are
> saved on a 2nd screen (windows were always displayed on the 1st
> screen).
> today this backfired, as while working with 1 screen (on a "2-screen"
> patch) not all windows of the patch were visible. canvas values were
> "#N
> canvas 1422 54" on pd file. While I salute the possibilty of having
> windows automatically appear on multiple screens, how about also
> making
> sure that they appear only in 1 screen of there aren't any more?
> E.g. if this window's X value is 1422 and my x resolution is 1400,
> probably subtracting the screen resolution of the window value
> should be
> enough. can tcl/tk get these elements? Another representation of
> what I
> meant:
> if canvasres >= screenres, then canvasres=canvasres-screenres (apply
> to
> both x and y)
I don't have a multi-monitor setup, so I can't test this. Ideally
you'd edit the code to get it working properly. It should be pretty
straightforward, the code in question is in pdtk_canvas.tcl in the
proc called 'pdtk_canvas_new'. You can see it gets the 'geometry'
from Pd as an argument to the proc, and is then set using "wm
geometry $mytoplevel $geometry" If you just do the math before
running the 'wm geometry' and put the right values into $geometry,
then 'wm geometry' should do the right thing.
> - some automatic redrawing while mousing over data structures (no edit
> mode, no clicking, just moving the mouse). sliders blink, and uses
> cpu for
> redrawing.
Yeah, there seems to be a bug in Tcl/Tk that makes the hover/cursor
change events trigger a window configure event, as if the window was
resized. I haven't figured that one out, can someone try their hand
at this one?
> - I get the impression that redrawing of data structures with toggle
> in
> the inlet (i.e. visible/invisible) is slower now. maybe just an
> impression? but anyway, is it possible to enhance this, is the gui
> work
> related with that?
Do you have an example patch?
> - I use the [hcs/sys_gui] command to make my own color scheme (white
> is
> too agressive) and to place the pd window on a corner (wm geometry).
> These
> don't work now, are they going to be obsolete, or they have to adapt
> to
> the new tcl code?
They should work fine, but the color scheme variables are part of Pd-
extended, this is still Pd-vanilla. I think you'd be better off
porting your color scheme to a Tcl plugin. Its not hard, plus you can
do a lot more with it.
http://puredata.info/dev/PdGuiRewriteTheming
> - font window: only works on patch if it's opened on a (any) patch
> window.
> if I do it from pd window, only affects pd window.
Ok, it was working for me on Windows and Mac OS X, but was behaving
oddly. I fixed the odd behavior.
> - x and y, x only + y only have all the same result. but I think
> that was
> the normal behaviour before anyway (never used this feature)
I've never used it either, I think it might be really old cruft...
> - I can only use courier now, wasn't verdana the latest standard?
> (maybe
> not)
It was Bitstream Vera Sans Mono with Pd-extended.
> - when I do a find in a pd window, it looks in the whole patch.
> wasn't it
> before that it only looked deeper from the call window, instead of the
> whole patch? (i.e., if I do find on the subpatch "aaa", it only
> searches
> on patches deeper than it)
> In case I was dreaming before, is it possible to make find work on a
> deep-only modus? I think this might be more logical for big patches
> (one
> can always go to the grandparent patch to search the whole thing)
This is also just a new interface to old Pd code, so its a separate
issue. File a bug/feature report if you want to follow up on it.
> - nice touch the "search in xxx.pd for"
> - what's exactly the "match whole work only" for? I searched for an
> incomplete string ("edit-ind" instead of "edit-index"), and neither of
> them found "edit-ind". besides for obvious purposes, this would be
> useful
> to find objects that have a $0 before - as replacing $0 by its number
> doesn't work in the search function.
That's the idea, but is perhaps buggy. That was introduced in Pd
0.42, so it separate from the GUI rewrite.
> - audio meters (in sc style?) are nice. but:
> - is it possible to start them in any menu/command besides the
> clickbox?
Same as old versions: [pd meters $1(
> - out button in connected to the actual sound volume of the
> system, and
> not to pd dac~ output (independently of how many there are). the
> latter
> would make more sense.
This is also just a new interface to old Pd code, so its a separate
issue. File a bug/feature report if you want to follow up on it.
> - dragging of patch fragments (several objects) around the canvas:
> works
> better in display purposes, but still uses lots of cpu (maybe even
> more?).
> anything can be done about that?
There are many things to do on that, but it'll take a fair amount of
work, so we'll need more contributions to get that done.
> - Help->About: Pd doesn't work (so I can't tell exactly which
> version it
> is)
Yeah... not implemented yet... it tells you the version at startup in
the Pd window.
> - Help->Html manual: opens up in internet explorer instead of
> opening up
> in my standard browser. that didn't happen before
It uses the internal Windows method for opening links, same as
before. That code is old.
> - Help->Browser: "ERROR: menu_doc_browser non-directory" pops up in
> the
> console.
> But the browser works. Btw, would it be possible to add scalable
> windows +
> key follow in the browser? (with key follow I mean that pressing "b"
> takes
> me to the first file with b in the window, "ba" to "ba...", etc etc
It would be very nice for sure, its just a matter of someone doing the
work. Any volunteers to redo the help browser?
> Anything else specific you want to be checked, Hans?
It would be great if you can use it for daily use, and report issues.
I'm starting a project where I will be doing the same thing. That's
where we will really discover bugs and issues.
.hc
>
> João
>
> --
> Friedenstr. 58
> 10249 Berlin (Deutschland)
> Tel +49 30 42020091 | Mob +49 162 6843570
> Studio +49 30 69509190
> jmmmpais at googlemail.com | skype: jmmmpjmmmp
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----------------------------------------------------------------------------
http://at.or.at/hans/
More information about the Pd-list
mailing list