Re: hyperlinks

[avijit ghosh <avijit ghosh pfizer com>]

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 ghosh 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" <hans 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
>