Hello all,
I've put my first version of "popup" the popup menu widget in CVS.
Its based on the button widget from GGEE, and has enherited some problems.
Its only lightly tested on linux, fairly tested on osx and untested on windows.
The biggest issues are: (which would help with other widget externals) * It shows up in a GOP abstraction, but when you move the abstraction PD can't find the widget path. (button from GGEE also does this) * popup is messy about its width (dependant on font size!). Best solution is to get the widget to report its size and fit the box accordingly. I know how to do this in tcl: [canvas] itemcget [tags] -width which does return the size in pixels, not characters. I would have fixed this already, but I don't know how to get the data from tcl/tk back to C, without it being treated as a method selector. (the output should not be bound to an outlet, but simply passed to an internal function that changes the box size) The result of this is the second outlet does not know where to be exactly!
Guenter, thanks for these examples and your help. I changed some code in the functions that draw the inlet and outlets by adding two tags, one for the particular outlet, and one for all the outlets. This way you can send one C command to erase all the outlets, rather than using a loop.
comments welcome.
Thanks all, Ben
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I've put my first version of "popup" the popup menu widget in CVS.
Cool. I'll test as soon as I finished testing the new Snd. ;)
But your check-in reminds me of another thing, I sometimes think about when looking at the CVS repository. You - and some others - put each external into its own directory. Another approach - that is taken by the larger collections like grill, ggee or creb rsp. pdp, is to put all externals by one author or those, that belong to a larger project, below a shared directory. I would prefer the second approach, partly because it makes organizing my own stuff easier.
What do the others think? Should this be unified a bit?
ciao
Hey Frank,
I think there should certainly be a protocol for the organization of the externals CVS. At first it seemed to make sens e to have everything at one level deep, but this came from my putting externals in CVS early on (too early?) I think there were only about 10 or so externals when I commited the first version of chaos, and have just followed that pattern since. I'm not sure if organization by author makes the most sense or not. (chaos is co-written by me and Michale McGonagle for example) I can imagine co-authorship might happen more often. For example "popup" is at least 80% from GGEE's button, so I would (at least) consider Guenter a co-author.
I'm really not sure the best organization, perhaps by types of externals?
control/ gui/ algo-generators/ ?
I'm very happy of the prospect of august's autoconf system to be the standard, I have no attachment to any of the build-systems of my externals and would be happy to make everything autoconf, I just need an easy to follow template.
Ben
Frank Barknecht wrote:
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I've put my first version of "popup" the popup menu widget in CVS.
Cool. I'll test as soon as I finished testing the new Snd. ;)
But your check-in reminds me of another thing, I sometimes think about when looking at the CVS repository. You - and some others - put each external into its own directory. Another approach - that is taken by the larger collections like grill, ggee or creb rsp. pdp, is to put all externals by one author or those, that belong to a larger project, below a shared directory. I would prefer the second approach, partly because it makes organizing my own stuff easier.
What do the others think? Should this be unified a bit?
ciao
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I think there should certainly be a protocol for the organization of the externals CVS. At first it seemed to make sens e to have everything at one level deep, but this came from my putting externals in CVS early on (too early?) I think there were only about 10 or so externals when I commited the first version of chaos, and have just followed that pattern since. I'm not sure if organization by author makes the most sense or not. (chaos is co-written by me and Michale McGonagle for example) I can imagine co-authorship might happen more often. For example "popup" is at least 80% from GGEE's button, so I would (at least) consider Guenter a co-author.
I'm really not sure the best organization, perhaps by types of externals?
control/ gui/ algo-generators/ ?
Actually "author" isn't meant literally. Of course many externals have several authors. In some cases it's just very practical to organize by "project" instead of semantically. For example, people like Thomas Grill can just mirror their whole private CVS tree to Sourceforge. And as one of the initial intentions of pd-SF was, to have as many externals as possible in one CVS, instead of them being spread all over the net. Then, grouping by "author" or "project" was a natural thing to do.
ciao
[Frank Barknecht]->[Directory structure [was: Re: [PD-dev] popup...
|Hallo, |B. Bogart hat gesagt: // B. Bogart wrote: | |> I've put my first version of "popup" the popup menu widget in CVS. | |Cool. I'll test as soon as I finished testing the new Snd. ;) | |But your check-in reminds me of another thing, I sometimes think about |when looking at the CVS repository. You - and some others - put each |external into its own directory. Another approach - that is taken by |the larger collections like grill, ggee or creb rsp. pdp, is to put |all externals by one author or those, that belong to a larger project, |below a shared directory. I would prefer the second approach, partly |because it makes organizing my own stuff easier.
i think every single way of categorizing the stuff is problematique because of manifold inclusions.
byauthor grouping does make sense for the more comprising packages but not for some single object efforts, also the author's name doesnt tell you anything about what the software does (cpan problem).
but since current filesystems hardly allow for heterogenous layouts its probly best to choose nice symbolic names like gem2pdp, arraysize, chaos, .. which lets you make a good guess about its purpose.
and then, cvs _and_ sf.net arent too friendly about directory reorganisation, so itd be some other piece of software's job to map the filesystem onto multiple modes of organization: byauthor, bycateg, byage, byname, ... pdb?
On Sun, 22 Feb 2004, d.lj wrote:
[Frank Barknecht]->[Directory structure [was: Re: [PD-dev] popup...
|Hallo, |B. Bogart hat gesagt: // B. Bogart wrote: | |> I've put my first version of "popup" the popup menu widget in CVS. | |Cool. I'll test as soon as I finished testing the new Snd. ;) | |But your check-in reminds me of another thing, I sometimes think about |when looking at the CVS repository. You - and some others - put each |external into its own directory. Another approach - that is taken by |the larger collections like grill, ggee or creb rsp. pdp, is to put |all externals by one author or those, that belong to a larger project, |below a shared directory. I would prefer the second approach, partly |because it makes organizing my own stuff easier.
i think every single way of categorizing the stuff is problematique because of manifold inclusions.
byauthor grouping does make sense for the more comprising packages but not for some single object efforts, also the author's name doesnt tell you anything about what the software does (cpan problem).
but since current filesystems hardly allow for heterogenous layouts its probly best to choose nice symbolic names like gem2pdp, arraysize, chaos, .. which lets you make a good guess about its purpose.
and then, cvs _and_ sf.net arent too friendly about directory reorganisation, so itd be some other piece of software's job to map the filesystem onto multiple modes of organization: byauthor, bycateg, byage, byname, ... pdb?
Yes, but in order to make this automatic, we could define a standard .txt file that can be parsed by pdb, containing keywords, categories, etc.
If pdb would offer this feature, every author of an external can supply a nice text description of the external and it would get automatically included in pdp, searchable, categorizeable etc.
Is pdb still maintained by Norbert ? Would be good to know what he thinks about this "addition".
Guenter
ah, PS: pdb doesn't solve the "how to organize the CVS" problem, though, it solves the "how to find an external" problem, which is different.
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Sun, 22 Feb 2004, d.lj wrote:
[Frank Barknecht]->[Directory structure [was: Re: [PD-dev] popup... and then, cvs _and_ sf.net arent too friendly about directory reorganisation, so itd be some other piece of software's job to map the filesystem onto multiple modes of organization: byauthor, bycateg, byage, byname, ... pdb?
Yes, but in order to make this automatic, we could define a standard .txt file that can be parsed by pdb, containing keywords, categories, etc.
This shouts for an RDF description...
ciao
On Fri, 20 Feb 2004, B. Bogart wrote:
Hello all,
I've put my first version of "popup" the popup menu widget in CVS.
Its based on the button widget from GGEE, and has enherited some problems.
I have "sort of fixed" the GOP behaviour. Generally I think I still have to get up to date with how GOP is handled in pd. Currently every move of a GOP forces me to delete and recreate the widget.
Guenter
Its only lightly tested on linux, fairly tested on osx and untested on windows.
The biggest issues are: (which would help with other widget externals)
- It shows up in a GOP abstraction, but when you move the abstraction PD
can't find the widget path. (button from GGEE also does this)
- popup is messy about its width (dependant on font size!). Best
solution is to get the widget to report its size and fit the box accordingly. I know how to do this in tcl: [canvas] itemcget [tags] -width which does return the size in pixels, not characters. I would have fixed this already, but I don't know how to get the data from tcl/tk back to C, without it being treated as a method selector. (the output should not be bound to an outlet, but simply passed to an internal function that changes the box size) The result of this is the second outlet does not know where to be exactly!
Guenter, thanks for these examples and your help. I changed some code in the functions that draw the inlet and outlets by adding two tags, one for the particular outlet, and one for all the outlets. This way you can send one C command to erase all the outlets, rather than using a loop.
comments welcome.
Thanks all, Ben
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
B. Bogart -
d.lj -
Frank Barknecht -
guenter geiger