On Aug 26, 2009, at 4:46 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Aug 26, 2009, at 3:44 PM, Frank Barknecht wrote:
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,Uhm, maybe you should look closer? :) Here I can minimize apps like
Firefox and Gvim and hide parts of their menubars and icons.Acutally I found, that I still can minimize the Pd main window, the
menus fold together.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
GOP is important for us, as the docs are for users to read. We've
chosen "REFERENCE" to not conflict with META, but of course that would be
easy to change.
AFAIK, the GOP status shouldn't affect the parsability. In the .pd
file, it just adds a "#X coords" line before the "#X restore" so it
would be easily ignored. Therefore, both GOP and non-GOP should be
fine.
- each comment is a whole chunk of data
Same here, just that "free" comments are allowed as well as additional description paragraphs for readability reasons.
How to you mark "free" comments? Once there are keywords, then those
can easily be mistakenly entered in the free comments. To keep the
parsing simple, it makes sense to keep the free comments out out of
the [pd META] subpatch. Then have a
This doesn't have to be any hard fast rule in the implementation. In
effect, if someone writes a comment without a recognized tag, it'll be
a free comment. But I think it would be a good convention to follow:
"each comment in [pd META] counts as a piece of data". There could
also be a comment tag, it could be "#" or "comment".
So like python style: don't force people to do the right thing, but
make the right thing easy to do.
- 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)
We have some 2-word keys, like "Outlet 0", so that is a tricky
decision. Anyway, as our system is mainly intended to be processed by
"smarter" text processing tools, the : doesn't hurt. But maybe we could add spaces
around it.
How about Outlet0, etc? Its really just a unique ID, so once parsed
the tag could be displayed as whatever.
These rules make it easier to parse in any language too. But I think
its important that the help patches be designed to be read by Pd
patches, since they are pd patches themselves.
- tags are space-separated not comma-separated (handling commas is a
pain in Pd)
Again, this is to include tags with more than one word, but I see
that for Pd parsing, the comma is nasty. However I guess with the text processing possibilities of tcl available in scriptlets, this may not be an
issue anymore.
It is not only a question of making the format easy to parse, but also
easy to create. Since it is text included in a Pd patch, it should
follow Pd's syntax rules. Pd is made from [selector arg arg arg], I
think these comments should have the same syntax.
Many tag interfaces use space-separated tags, its a common idiom. It
makes sense with Pd too.
Generally the "pd REFERENCE" idea was to have a most simple,
externally parsable and user-readable reference system. META is cool and was an
obvious inspiration, but the rest of PDDP was deemed much too bloated with
layout conventions and color coding and cnv-paintings and similar stuff to
be useable for us. Help files IMO should be written, not designed.
We are only talking about [pd META], I also agree the PDDP stuff ended
up somewhat bloated. I think we are agreed on the [pd META] goals: as
simple as possible, parsable, user-readable. I hope we don't end up
with a separate, incompatible format unless there is a really good
reason for it.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne