Hello all,
Thanks to everyone who has helped me out over this learning experience, especially Krzysztof who has spent a lot of time on my questions.
Ok I have two questions today. After getting my text widget to talk to PD I have a functional (so I thought) external, only in need of some cleaning up. To my great dismay I copied the source over to my linux machine and "text" seems to think its a standard non-gui object!!! All the methods are there and accessible, the only errors I get are that it can't find the widget path. Interestingly the widget path always starts with .x0. where "0" should be printf("%x", x->x_glist) As far as I can tell the glist stuct member is containing something completely different on OSX than in linux (but popup works on linux, and I changed nothing in the glist stuff, copied directly over).
I debugging I put posts in functions: create_widget, text_drawme (in if(firsttime) and else(firsttime), text_displace and text_vis. None of these posts end up on the console.
Now that I have this terrible bug, I would like anyone who has the experience and time to take a look.
So where should I put "text" in CVS? along side chaos, popup, and pso in the root? Or make a "bbogart" directory to contain these? or leave pso and chaos and put popup and text in a "gui-externs" directory? The code is almost identical to popup, all I changed was the tcl stuff and changed the object methods, which all just do sys_vgui things.
Any help would be appreciated. I was hoping to keep on with the posts, but since none of these methods seems to even get called, its a issue that far exceeds the depth of my pd knowledge. :( I don't even understand what a glist is. *sigh*
Thanks everyone, I hope at least some of you also have applications these things would be useful for.
Oh I have one more question, the text widget likes to hold onto keyboard focus once it has been focused (with mouse) so one can't use the keyboard in the patcher without unfocusing the text widget (Ctrl-tab). I fixed this by binding the <Leave> event on the text widget with a focus command on the widget's parent (focus [winfo parent]) I'm not sure if this is safe to do in all circumstances. But it does seem to work well.
Thanks! (with great enthusiasm) Ben
PS: I'm teaching another lot of University students pd/Gem next week.
hi Ben,
B. Bogart wrote: ...
I can tell the glist stuct member is containing something completely different on OSX than in linux (but popup works on linux, and I changed
do not blame linux for that. What you need is
x->x_glist = canvas_getcurrent();
in the _new routine. Assigning it in a draw routine does not make sense, because the value never changes during the object's lifetime. If you do so, you are going to rely on the draw routine being called prior to any usage of x->x_glist.
...
and chaos and put popup and text in a "gui-externs" directory? The code is almost identical to popup, all I changed was the tcl stuff and changed the object methods, which all just do sys_vgui things.
exacly the reason, why the efforts would be better channeled, if they went into creating the generic Pd framework for Tk widgets...
...
fixed this by binding the <Leave> event on the text widget with a focus command on the widget's parent (focus [winfo parent]) I'm not sure if
more natural, perhaps, seems keeping the focus in the widget, even if mouse is outside of it (keep it until clicked outside) -- that is how text editors usually behave. What I do is just
bind Canvas <1> {+focus %W}
in the setup.wid. Actually, I would like to have it in pd.tk, instead...
Krzysztof
Thanks for the answers Kryzysztof,
What is the difference between what you suggest and what Guenter had in button.c originally:
x->x_glist = (t_glist*)NULL;
I accidentally commented both yours and his out and it still works?
The issue was (simple) and I would not have noticed it if Mathieu had not brought my attension to it, but the existance of a "text" class already! After renaming the external to "entry" it all works fine. I really have no idea why OSX swallowed my mistake.
I completely agree that a better way of dealing with tk widgets (and perhaps any other toolkit for that matter) in PD is the best solution. This is certainly in no dispute, and I would be happy to help with the tk portions of this project. These externals are a short term solution that I can justify spending a few days on (two for popup and two for text). I do think these externals will be useful in a number of situations now, but hope they will be replaced by toxy in the future. (native widget listbox w/ scrollbar!)
In terms of focus, I was expecting the pd canvas to automatically take the focus back when clicked, but this does not happen. Sounds like this binding should be in PD to avoid issues with any focus grabbing widgets in the future. I'm not going to mess with the bindings of the parent canvas in this external though and suppose I'll leave it this way for now. Seems to work fine in GOPs as well.
Any suggestions on the CVS structuring issue? Or should I not put entry into it quite yet?
B.
Krzysztof Czaja wrote:
hi Ben,
B. Bogart wrote: ...
I can tell the glist stuct member is containing something completely different on OSX than in linux (but popup works on linux, and I changed
do not blame linux for that. What you need is
x->x_glist = canvas_getcurrent();
in the _new routine. Assigning it in a draw routine does not make sense, because the value never changes during the object's lifetime. If you do so, you are going to rely on the draw routine being called prior to any usage of x->x_glist.
...
and chaos and put popup and text in a "gui-externs" directory? The code is almost identical to popup, all I changed was the tcl stuff and changed the object methods, which all just do sys_vgui things.
exacly the reason, why the efforts would be better channeled, if they went into creating the generic Pd framework for Tk widgets...
...
fixed this by binding the <Leave> event on the text widget with a focus command on the widget's parent (focus [winfo parent]) I'm not sure if
more natural, perhaps, seems keeping the focus in the widget, even if mouse is outside of it (keep it until clicked outside) -- that is how text editors usually behave. What I do is just
bind Canvas <1> {+focus %W}
in the setup.wid. Actually, I would like to have it in pd.tk, instead...
Krzysztof
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
hi Ben,
B. Bogart wrote: ...
The issue was (simple) and I would not have noticed it if Mathieu had not brought my attension to it, but the existance of a "text" class already! After renaming the external to "entry" it all works fine. I
well, in fact, the only source of conflict is the symbol 'text_widgetbehavior'.
So, there should not be any problem in creating an external "text" class. The internal text_class is static, and it does not register its new method. You would only need to rename your widgetbehavior structure to something other than the internal name.
However, even if it is possible, doing so looks like a bad style, probably...
...
Any suggestions on the CVS structuring issue? Or should I not put entry
ask Guenter?
Krzysztof
On Thu, 11 Mar 2004, Krzysztof Czaja wrote:
B. Bogart wrote:
Any suggestions on the CVS structuring issue? Or should I not put entry
ask Guenter?
Seems that the structure that is best accepted by the developers is to have a subdirectory for each developer. If you want your externals to be compiled by the general build system in the "build" subdirectory you just have to make a "link" in build/src (look at one of the examples in build/src how this is done, in general it is just a "include" statement).
Greetings,
Guenter
Krzysztof
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hey Guenter,
Will I have any issues with moving a number of externals into the future "bbogart" directory? (obviously I'll have to edit paths in the build system) Is there anything else I should be aware of before moving chaos, pso and popup into this new directory?
Thanks Ben
guenter geiger wrote:
On Thu, 11 Mar 2004, Krzysztof Czaja wrote:
B. Bogart wrote:
Any suggestions on the CVS structuring issue? Or should I not put entry
ask Guenter?
Seems that the structure that is best accepted by the developers is to have a subdirectory for each developer. If you want your externals to be compiled by the general build system in the "build" subdirectory you just have to make a "link" in build/src (look at one of the examples in build/src how this is done, in general it is just a "include" statement).
Greetings,
Guenter
Krzysztof
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Mon, 15 Mar 2004, B. Bogart wrote:
Hey Guenter,
Will I have any issues with moving a number of externals into the future "bbogart" directory? (obviously I'll have to edit paths in the build system)
You mean you have to update the existing links in order to point to the new locations of your plugins ? Yes - Please.
Is there anything else I should be aware of before moving chaos, pso and popup into this new directory?
No actually not. In your own directory you can more or less do what you want.
Guenter
Thanks Ben
guenter geiger wrote:
On Thu, 11 Mar 2004, Krzysztof Czaja wrote:
B. Bogart wrote:
Any suggestions on the CVS structuring issue? Or should I not put entry
ask Guenter?
Seems that the structure that is best accepted by the developers is to have a subdirectory for each developer. If you want your externals to be compiled by the general build system in the "build" subdirectory you just have to make a "link" in build/src (look at one of the examples in build/src how this is done, in general it is just a "include" statement).
Greetings,
Guenter
Krzysztof
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
If you are not in a rush, I could email the sourceforge helpdesk (as an admin) and have them move it. The advantage with this approach is that all of the revision info would be preserved. It takes them a week or two usually.
.hc
On Monday, Mar 15, 2004, at 09:09 America/New_York, B. Bogart wrote:
Hey Guenter,
Will I have any issues with moving a number of externals into the future "bbogart" directory? (obviously I'll have to edit paths in the build system) Is there anything else I should be aware of before moving chaos, pso and popup into this new directory?
Thanks Ben
guenter geiger wrote:
On Thu, 11 Mar 2004, Krzysztof Czaja wrote:
B. Bogart wrote:
Any suggestions on the CVS structuring issue? Or should I not put entry
ask Guenter?
Seems that the structure that is best accepted by the developers is to have a subdirectory for each developer. If you want your externals to be compiled by the general build system in the "build" subdirectory you just have to make a "link" in build/src (look at one of the examples in build/src how this is done, in general it is just a "include" statement).
Greetings,
Guenter
Krzysztof
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
B. Bogart -
guenter geiger -
Hans-Christoph Steiner -
Krzysztof Czaja