[PD-dev] [ pure-data-Bugs-1818219 ] namespace prefix not included in save functions

SourceForge.net noreply at sourceforge.net
Mon Oct 29 19:59:40 CET 2007


Bugs item #1818219, was opened at 2007-10-22 18:50
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1818219&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
>Group: v0.40.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: stffn (stffn)
>Assigned to: Hans-Christoph Steiner (eighthave)
Summary: namespace prefix not included in save functions

Initial Comment:
1. Open the attahced patch in Pd-extended.
2. Notice the both [list-abs/wrandom] and [unauthorized/grid] gets created.
3. Save the patch whit out making any chages.
4. Close the patch.
5. CLose Pd-extended.
6. Open the patch again.
7. See that the grid objects doesn't get created and (since) the the prefix has been removed.

This happens in Pd-extended-0.39.3 mac intel.

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-29 14:59

Message:
Logged In: YES 
user_id=27104
Originator: NO


Thru this thread, we figured out the fix:

http://lists.puredata.info/pipermail/pd-dev/2007-10/009797.html

Here's how to get the whole classname in the save function:

static void entry_save(t_gobj *z, t_binbuf *b)
{
    t_entry *x = (t_entry *)z;
    t_symbol *classname =
atom_getsymbol(binbuf_getvec(x->x_obj.te_binbuf)),

    binbuf_addv(b, "ssiisiiss", gensym("#X"),gensym("obj"),
                x->x_obj.te_xpix, x->x_obj.te_ypix, 
                classname,
                x->x_width, x->x_height, x->x_bgcolour, x->x_fgcolour);
    binbuf_addv(b, ";");
}

I added this fix to these objects: 

bbogart/popup/popup.c
ffext/tracker/tracker.c
footils/knob/knob.c
ggee/gui/button.c
ggee/gui/gcanvas.c
ggee/gui/image.c
ggee/gui/slider.c
ggee/gui/sliderh.c
ggee/gui/ticker.c
ggee/gui/toddle.c
ggee/gui/w_envgen.h
hcs/cursor.c
miXed/cyclone/hammer/Table.c
miXed/cyclone/hammer/comment.c
miXed/cyclone/hammer/funbuff.c
miXed/cyclone/sickle/Scope.c
miXed/toxy/widget.c
moonlib/gamme.c
moonlib/image.c
moonlib/mknob.c
pdvjtools/colorgrid/colorgrid.c
pdvjtools/imagegrid/imagegrid.c
pdvjtools/videogrid/videogrid.c
pidip/modules/pdp_colorgrid.c
unauthorized/audience~/audience~.c
unauthorized/cooled~/cooled~.c
unauthorized/exciter/exciter.c
unauthorized/filterbank~/filterbank~.c
unauthorized/grid/grid.c
unauthorized/pianoroll/pianoroll.c
unauthorized/probalizer/probalizer.c
unauthorized/scratcher~/scratcher~.c
unauthorized/scrolllist/scrolllist.c
unauthorized/sonogram~/sonogram~-joge.c
unauthorized/sonogram~/sonogram~-yves.c
unauthorized/sonogram~/sonogram~.c

That leaves the code in externals/iem, pd/src/, and some of the more
complex objects in externals/miXed.



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-26 23:32

Message:
Logged In: NO 

yeah, because of the m_imp.h inclusion, this is a problem. it could be
solved by adding a function to m_pd.h that returns the class name as a
symbol or C string, whichever is more convenient. i think that it's much
easier than changing the interface.

otherwise, you could make another class_setsavefn that would register the
fact that you want the 5 atoms "#X" "obj" x1 y1 classname to be written
before the savefn is called. The original has to be kept both because of
backward-compatibility and because it's possible to make externals that
have a subpatch-like behaviour (though no-one has tried doing that yet!)

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-26 12:12

Message:
Logged In: YES 
user_id=27104
Originator: NO

If every patch is going to add (*(t_pd *)x)->c_name->s_name to the savefn,
then it seems to me that there should be a mechanism in Pd itself to do
this automatically.  Then the interface might need to be different.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-25 21:14

Message:
Logged In: NO 

hans, it's not the meaning of t_savefn itself that has to be changed: it's
just every use t_savefn, that is, every blah_savefn function that gets
registered, if they aren't already using (*(t_pd *)x)->c_name->s_name.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-25 13:24

Message:
Logged In: YES 
user_id=27104
Originator: NO


This sounds like an excellent idea!  I think that this improved savefn
will probably need to be distinct from the current savefn stuff, since it
probably wouldn't be compatible.  But if it could be the same mechanism,
that would be even better.

----------------------------------------------------------------------

Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-24 05:42

Message:
Logged In: YES 
user_id=564396
Originator: NO

i changed the category, since it is a problem with pd (though it affects
externals)

i changed the name, because it is not gui-specific: every object that
defines a savefn() is affected by this (usually only gui-classes do this
because they are the classes where you cannot directly edit the arguments
(being hidden) and which might offer a properties window to change these
arguments)

however: i think it is a great feature that an object is able to change
it's own name (really).
nevertheless, an object should also be able to _query_ it's own name.
this is usually not a big problem because the object assumes that it knows
how it is called (the name the dev gave it).
when using namespaces this is not the case any more.

basically: the object would need a way to easily query it's own name (i am
sure it is somehow possible via weird t_canvas/t_class/t_obj/t_pd/...
pointer magic which is so complicated i will have to re-read to source
code)

the savefn() should provide a way to set object-name and arguments
separately, the object-name should default to the actual name (not the
canonical one) if not set otherwise.


----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-23 20:50

Message:
Logged In: YES 
user_id=27104
Originator: NO


I found the root of the problem, if the GUI object has a savefn, then that
savefn needs to include the whole classname, including the namespace
prefix.

I think  stffn was right, it does apply to all GUIs.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-23 17:09

Message:
Logged In: YES 
user_id=27104
Originator: NO


This doesn't happen to all GUI objects, just some.  I think [grid] is one,
but many others work fine with the prefixes.  

----------------------------------------------------------------------

Comment By: stffn (stffn)
Date: 2007-10-23 03:44

Message:
Logged In: YES 
user_id=1658640
Originator: YES

True, this also happens in Pd version 0.40-2.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-22 19:40

Message:
Logged In: YES 
user_id=27104
Originator: NO

This happens on Pd-0.40.3-extended-20071021 on Mac OS X also.  Has anyone
tested this on other GOPs? I know pddp/pddplink works fine.  Also
cyclone/Scope~ also works.  I think this might be an issue with the objects
themselves.

----------------------------------------------------------------------

Comment By: stffn (stffn)
Date: 2007-10-22 18:52

Message:
Logged In: YES 
user_id=1658640
Originator: YES

I forgot to mention that it happens to quite many if not all the GUI
objects. At least those in CVSROOT/doc/pddp/about/GUIs-about.pd.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1818219&group_id=55736




More information about the Pd-dev mailing list