Hi Hans, apologies for not getting back to you sooner. For obvious reasons I totally agree that in no way should any of the particular examples be hardwired into the dia code base. In fact I am not particularly comfortable with them even being custom widgets that themselves are hardwired to the code base. Rather I'd like the extensibility to be such that it would be easy to generate the examples below by simply creating an appropriate .shape file. That said, it seems to me the only way to generate custom shapes is via the ext_attributes set so I am a bit confused with the use of ext_attributes being depreciated. (Is there a better way now?).
Let me actually send you a proposal in a little bit that is a formalized proposal for our coders. It uses (unfortunately) the ext_attributes bit but perhaps the proposal itself will give you more of a sense of what it is I am trying to do and you could give me/us some advice on how to do this properly (rather than simply extending ext_attributes). This way we don't mess up your codebase with something that can't contributed back.. -regards. -avi On 6/30/09 2:35 PM, "Hans Breuer" <[email protected]> wrote: > At 26.06.2009 18:22, avijit ghosh wrote: >> Hey Hans I just had a chat w/ our coders and they are going to meet next >> Thursday to see if they take this on. If they do not, I will do this myself >> in my spare time as it'll certainly be useful. I think you are absolutely >> right, it would be better to put it in as a regular property for all objects >> I'll take a look at prop_dict.c. My only fear with putting as a standard >> property is many of my objects would have multiple links to the outside (and >> ideally they may be embedded multiple links) so basically right now when I >> click a particular thingy I currently have the following show up: >> >> >> Below the standard dialogue box (line width and so forth) >> >> Gene Symbols [ comma separated list of strings ] >> Gene IDs [ comma separated list of integers ] >> Exp Value [ comma separated list of reals ] >> > Stuff like that should definitely not be added to all objects, but to > specific shapes (if at all :)) > >> >> What I want to add is the ability to hack it so it looks like this: >> >> Gene Symbols [ comma separated list of strings ] >> Gene IDs [ comma separated list of integers ] >> Exp Value [ comma separated list of reals ] >> NCBI Info [ comma separated list of URLs ] >> KEGG Info [ URL ] >> Internal Database 1 [ comma separated list of URLs ] >> > This still looks very specific to your particular use case. But of course > every object could have different meta info attached. > >> I can auto fill in the what those urls actually are from the gene symbol >> list.. >> >> So there need to be more than one URL per object.. Would the standard >> dialogue still let me do this or would each object only have one link? >> > The standard dialog should certainly allow to add any meta info (key:value > pair) you want, and the backend already does support this. But my idea is > to have some well known keys which could be supported by other parts of the > application, e.g. following a link would be: > > if ((val = dia_object_get_meta(obj, "url") != NULL) { > gtk_show_uri (gdk_screen_get_default(), val, GDK_CURRENT_TIME, NULL); > g_free (val); > } > > and mapped to some always available context menu entry. > >> Incidentally if ext_att is depreciated what is the new notation? Will there >> be a way to convert over? I think I am just using whatever dia generated at >> some point and that file just gets edited by perl scripts.. >> > There is no replacement for ext_attributes yet and maybe there never will. > But building further features on top of it should be avoided, this is why I > said: "should be considered deprecated" ... > > Hans > > -------- Hans "at" Breuer "dot" Org ----------- > Tell me what you need, and I'll tell you how to > get along without it. -- Dilbert > > _______________________________________________ > dia-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/dia-list > FAQ at http://live.gnome.org/Dia/Faq > Main page at http://live.gnome.org/Dia > _______________________________________________ dia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
