On Sun, 17 Jul 2005, Tim Blechmann wrote:

...

source/flbase.cpp:28:22: error: g_canvas.h: No such file or directory

to compile flext, you need pd's private headers ... most likely the debian package doesn't install them to /usr/include ... which makes it impossible to compile cyclone, flext .... possibly yves externals ...

It wouldn't be a problem to change the debian package to include these headers, but pd itself doesn't install them. I am always trying to stay as close as possible to the authors compilation and packaging system, because they know best. Then, there is a debian package for flext, so why not use this and solve the compilation problem together (againandagainandagainandagain)

Guenter

t

-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk

latest mp3: kMW.mp3 http://mattin.org/mp3.html

latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/

After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

On Sun, 17 Jul 2005, Tim Blechmann wrote:

...

It wouldn't be a problem to change the debian package to include these headers, but pd itself doesn't install them.

right ... in theory no external developer should use these headers, but what does grep -r g_canvas.h /path/to/pd/externals tell you? in fact, you can't build a lot of externals without these headers ... but on the other hand, no one has to use cyclone, flext, iemlib, toxy, yves externals or your gui externals ... ;-)

So whats the point that you want to make with that ? I understand Miller that he doesn't want to export this file, because the whole point on Pd is that this should be handled differently. I didn't know that when I started using g_canvas.h, others followed to do so and so I feel responsible for having started this (and, in fact having delayed in some way the acceptance of the data structures).

...

Then, there is a debian package for flext, so why not use this and solve the compilation problem together (againandagainandagainandagain)

well, there are people out there, who would like to make use of the features in devel like having a threadsafe gui or lockfree thread synchronisation using idle callbacks ...

there surely are, in this case the missing g_canvas.h is a problem of the devel version ?

Guenter

cheers ... tim

-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk

latest mp3: kMW.mp3 http://mattin.org/mp3.html

latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/

After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

On Sun, 17 Jul 2005, Thomas Grill wrote:

i'm asking myself how this should be handled then... In my understanding there should be no relevant difference between internals and externals, meaning that both should use the same API. What is the solution for external developers? Not implement graphical stuff at all? Or do it with data structures, wasting development time and system resources?

I think it should be handled by not implementing graphical stuff at all or by doing it with data structures, but wasting development time and system resources should be avoided.

No, honestly, I am for a stable graphics API. I even think all the drawing stuff should be wrapped into an API instead of sending it as tcl/tk commands to the canvas directly. If this is done throughout pd, you can reimplement the canvas as an OpenGL window and do scaling, zooming rotating and other fancy stuff with your patch, and the drawing is fast.

It seems the common problem is that things in PD development got and get messed up by the time because people want to work with the API and implement useful things but it's totally unclear what future directions will be, what can be used safely etc. It's a problem of documentation and communication.

Yes, this was one of the goals that I had in mind when creating the CVS. Unfortunately we haven't been able to define a clear direction, and then this is terribly difficult because everyone will have another opinion in which direction Pd should go. (remember the endless single external versus library discussions ?) That is also why I (hope at least) try to enforce the direction of Miller, Pd is his program and he is the authority. It is obvious that one of the main interests currently are the data structures, and honestly, I find this a lot more interesting than coding yet another graphical external. I have a terribly bad memory and my main concern is to have a possibly small basic set of objects that I can use to build my patches. Currently the external business is going in the other direction and this scares me because I can't follow all the new and fancy developments that are happening.

Concerning flext, it uses g_canvas.h quite conservatively and i think it would be even possible to avoid it with the loss of some comfort (attribute editor).

I think this is a very wise decision.

Guenter

best greetings, Thomas

On Sun, 17 Jul 2005, Thomas Grill wrote:

...

I think this is a very wise decision.

First, the user should decide - i'm not about to throw it out, but there should be a preprocessor definition for it. Second, it's not as easy as i thought because the whole attribute mechanism depends on $-aware saving and reloading. canvas_realizedollar is needed for that, like in the iem-guis. It's one of the examples where internals are obviously differently treated from externals. It seems a solution would be that all externals are put into pd itself, so there's no need for an API.

:) I think the best solution is to talk about what is used and try to make it into a stable API. This will be hard though, especially a function like canvas_realizedollor sounds too much like a hack to be a serious candidate for a stable API .. back to escaping.

Guenter

best greetings, Thomas

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

On Mon, 18 Jul 2005, Guenter Geiger wrote:

...

canvas_realizedollor sounds too much like a hack to be a serious candidate for a stable API .. back to escaping.

Forget about this. Probably doesn't have to do with escaping, nor that the function is a hack. I think this one is not exported because it used to be handled internally without the externals (or internals) need to worry about. Now this seems to have changed.

The whole mechanism of dealing with $-variables in object creation arguments (like in iem-guis and flext) is awkward. In my case (and i think also with iem-guis) the $s are converted to #s on saving. On object creation, the #s are converted back to $s in the object constructor and evaluated by canvas_realizedollar. It would be advantageous to have some less hacky procedure here.

best greetings, Thomas

On Sun, 17 Jul 2005, Guenter Geiger wrote:

So whats the point that you want to make with that ? I understand Miller that he doesn't want to export this file, because the whole point on Pd is that this should be handled differently. I didn't know that when I started using g_canvas.h, others followed to do so and so I feel responsible for having started this (and, in fact having delayed in some way the acceptance of the data structures).

No, the problem with the "data structures" is that they are insufficient to create good GUIs. Then, one could speculate about how everybody could have collaborated on improving the "data structures", but it would've required approval from Miller. Thus g_canvas.h was the easiest path.

Direct mapping between structure elements and visual characteristics is quite limiting. Imagine if instead each "data structure" had one (or more) associated abstractions that could process the fields' values before they are displayed or before the user's actions modify the fields' values. This would allow for much richer behaviour.

,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'