Hey as I am I am looking over this. I was just thinking .. Maybe the easiest way of doing this is getting <dia:string> to understand basic markup. This would make everything work immediately without any real customization needed. What I mean by this is for instance if one used BBCode markup
<dia:string> [url=http://www.google.com]Life is Rocking[/url],[url=http://www.stupid.com]Life is stupid[/url] </dia:string> If dia:string allowed us to do this it would be simple to get everything else to work since URL links would simply show up automagically.. -regards. -avi On 7/7/09 10:18 AM, "Avijit Ghosh" <avijit.gh...@pfizer.com> wrote: > 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" <h...@breuer.org> 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 >> dia-list@gnome.org >> 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 > dia-list@gnome.org > 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 dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
