[PD] Report on Pd-0.43.0-devel-windowsxp-i386.exe on windows xp
Hans-Christoph Steiner
hans at at.or.at
Thu Oct 15 17:58:24 CEST 2009
On Oct 14, 2009, at 8:19 PM, João Pais wrote:
>>> - alt-[key] doesn't work on menus? alt-f should make file menu open
>>
>> Does that work on other versions of Pd?
>
> the only other version I have is vanilla 0.42-5. guess what, it
> doesn't work as well. probably it never did.
> would it be part of the job now to make it work?
Sure, sounds like something good to have. Do you want to take on that
project?
>>> - 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.
>
> actually I never used the text editor, and don't know if anyone did
> (the data structures editor yes, but that's independent). maybe it's
> better just to take it out?
>
>
> - remembered something that I sugested already: what about return
> closes an object while typing? eliminates the need for an extra click.
>
> - how about also making the line breaks on comments to work, would
> it go into this work batch?
>
>
>>> - 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.
>
> the problem is that the only language I can program in is Pd. C and
> others I don't really know how to do anything.
> It should be very easy to test for you, in case you want to: just
> open your pd file in a text editor, locate any line that defines a
> windows - format "#N canvas 914 187 335 381 gui 0;", being "gui" the
> window name -, and add 1000 or something to the first number (x
> position). If you can't see it when you open the patch in pd, it
> means it's still not ok.
Tcl is not hard, and there is nothing to be lost by trying it. :-D
>>> - 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 have a complicated patch with some structures in it, I can send to
> it you later. but I guess any patch will do - including your solitude.
Ideally there would be a patch that clearly illustrates the problem
and nothing else.
>>> - 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
>
> sorry, but I can't understand what "you can drop them into pd/
> startup" means. I see no folder or file with that name here.
Its not getting installed yet on Windows. You can create 'startup' in
the folder where you installed Pd 0.43/gui-rewrite (\Program Files\pd
by default). Then you can drop and *-plugin.tcl file there to have it
loaded when Pd runs. Here are some of the plugins available:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-gui-rewrite/0.43/startup/
.hc
>>> - 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 would ask the higher powers (miller/iem people) and get rid of it.
>
>
>>> - 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.
>
> Pd version 0.43-0devel-20091008, in case it's important to know.
>
>
>>> 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.
>
> should be doing that from tomorrow, maybe. doesn't the ubuntu
> version comes with the pd-ext material, like the windows one?
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent controls
you." - Richard M. Stallman
More information about the Pd-list
mailing list