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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list