[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