[PD] pd 0.43 branch with the new GUI code

[Hans-Christoph Steiner]

On Aug 26, 2009, at 3:44 PM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> It won't let you go smaller than the menubar on the window.
>
> I think, being able to make a window smaller should be a default  
> action/script,
> as it is with the old Pd. It definitely should be possible without  
> externals.

Ok, so a scriptlet it is.  I've never seen any other app that allows  
you to shrink further than the menubar, for apps that are the menubar  
type (i.e. not emacs.  The GNOME apps generally don't.

>> That is Federico's system based on tags.  Its also a plugin.
>> "object_db.tcl".  Change it and you can have your own custom  
>> system!  I
>> think it could be really cool if this plug parsed all the help  
>> patches
>> for tags, and built the menu based on that.  Currently, its close to
>> that, but uses an included database instead of parsing the help files
>> directly.
>
> Which reminds me to quickly hint at the system for "parsable" help  
> files we
> have introduced into the rj library for rjdj recently. There each  
> help file
> has a subpatch called "pd REFERENCE", which is GOP so the contents are
> readable from the parent.
>
> This subpatch only contains comments, which act like key:value  
> pairs. Example:
>
>  Name: e_alias
>  Summary: distort by reducing the sample rate to generate aliasing
>  Argument 0: name for state saving (required)
>  Argument 1: aliasing factor (optional)
>  Inlet 0: audio signal to distort
>  Outlet 0: alias-distorted audio signal.
>  Description: distorts any audio signal by reducing
>  the sample rate to generate aliasing.
>  Non-key comments are added to "Descripton" in y-order.
>  Tags: distortion, effect
>
> Not all help files have been converted to this format yet, but the  
> idea is to
> make html or other docs from these comments. Think of them like  
> docstrings in
> Python.
>
> Maybe this can be used for a better help browser, too. But I tell you,
> converting help files to this is a lot of tedious work. :) And we  
> don't even
> care for any graphical layout conventions (deliberatly).
>
> But it keeps the docs close to Pd which IMO is better than manually  
> editing
> webpages.

Its a good idea and something that should definitely happen. That's  
why its part of the PDDP templates (http://puredata.info/dev/pddp) but  
unfortunately not widely implemented.  How about following that spec,  
its close, but a bit simpler and designed to be easily parsed in Pd:

* the subpatch is called [pd META], and is not GOP
* each comment is a whole chunk of data
* the first word/atom is the datatype (i.e. no : at the end of it),  
case insensitive (removing a : in Pd is a little annoying)
* tags are space-separated not comma-separated (handling commas is a  
pain in Pd)

>>> - when running from "./bin" rsp. "./src" now, no helpfiles are found
>>> ("about"
>>> is empty, too). It was very nice that Pd so far was able to be run
>>> from there
>>> without installation.
>>
>> I've been instead running everything in "src/" so that no files  
>> have to
>> be moved when development.  The 'bin' thing should only be used  
>> with a
>> 'make install'.  There is no need to move files if you are not  
>> doing a
>> "make install".
>
> I don't really care if files are in bin or src. (For some reason,  
> bin is a
> symlink to src anyway) But neither lets me open any help files when  
> starting Pd
> as "cd src; ./pd", which definitely was possible with previous Pds.   
> Maybe I'm
> doing something wrong?

Strange it works for me on Ubuntu and Mac OS X. Where is it looking?

.hc


----------------------------------------------------------------------------

The arc of history bends towards justice.     - Dr. Martin Luther  
King, Jr.