This might need much cut'n'paste between apps to get the browser launching bits going. It might be a good idea to export the default browser info via XSettings in g-s-d so we can avoid that duplicated code.

Great, thanks for doing this! FWIW, this is the only sexy bit I use in PolicyKit-gnome and I'd love to see it go into the next GTK+ release.

(In reply to comment #1)
> This might need much cut'n'paste between apps to get the browser launching bits
> going.

GtkLinkButton would also benefit from this. in the mean time, the label should probably use a hook function like the LinkButton.

about naming, LinkLabel would probably fit in better than UrlLabel.

I'm working on this right now (and thanks for the input everyone!), but I'm wondering if it's possible to do without breaking binary compatibility would it be a good idea to try to integrate this functionality into GtkLabel instead?

I want to get GtkLinkLabel finished using your suggestions first, but if people like the idea of juicing up GtkLabel instead then it should be really easy to move all of this code into it.

Emmanuele, what is the purpose of the hook func rather than using a signal?

(In reply to comment #5)
> Emmanuele, what is the purpose of the hook func rather than using a signal?
> 

The signal would have to be connected for each single GtkLinkLabel. If you have many of them and forget one by accident, your app is broken. With a global hook you have to remember that step just once. 

Ideally GTK+ even would setup a default handler using XSETTINGS/xdg-open/BROWSER/whatever to open an URL. That default handler would be used by GtkAboutDialog, GtkLinkButton and GtkLinkLabel.

We should give this enough thought before rushing the merge.  Eventually one should be able to tag parts of text in a text buffer as a link and have it just work too, using the same browser setting...  And yes, I prefer just modifying GtkLabel instead of a new widget.

Yeah, I don't want to rush anything.  But I feel like a good first iteration of this patch should be getting the Sexy widget converted over to GTK and get the default URL handling stuff working.  Once that's done, it shouldn't be terribly difficult to abstract all the URL handling stuff so that it can be used by GtkLabel and GtkTextView.

I have to go to California next week and work from the office, so I probably won't have any time to invest in this during that time.  I'm going to go ahead and attach the GTKified widget as it is right now.  There is no default-handler code in here yet, the hook doesn't work yet (I was adding it this morning and got distracted to practice for my quartet rehearsal :) ), but I'm going to go ahead and post it as-is anyway.

Created attachment 102788 [details] [review]
Very unfinished :)

Adding Epiphany-maint in cc

What is GtkLinkLabel providing which GtkLinkButton isn't?
I don't think there's should be more than one widget in Gtk+ which opens a link.

(In reply to comment #11)
> What is GtkLinkLabel providing which GtkLinkButton isn't?

you can set a link inside some other text, like:

  this application creates <a href="http://lolcats.com">lolcats</a> images

and set it into a label; the other way to implement this with a GtkLinkButton would be:

  GtkHBox homogenous:false, spacing:6
  +---- GtkLabel text:"this application creates"
  +---- GtkLinkButton uri:"http://lolcats.com, label:"lolcats"
  +---- GtkLabel text:"images"

which is kind of ugly, albeit perfectly doable.

the way I see it, it's the ability of setting a PangoLinkAttribute to any text set into a GtkLabel or a GtkTextBuffer that should be added; the default action would exactly be the same used by GtkLinkButton.

(moving back severity to enhancement, this is a new feature)

> the way I see it, it's the ability of setting a PangoLinkAttribute to any text
> set into a GtkLabel or a GtkTextBuffer that should be added; the default action
> would exactly be the same used by GtkLinkButton.

That would be nice. But it certainly needs GTK+ level support, eg to set the appropriate pointer etc.

Is this work still in progress or stopped?

I haven't worked on it recently.  I'm finishing up merging SexyIconEntry first, and then I was going to work on this next.

Thanks, Russell. I am just curious about if the work is still in progress. Do you have any plan in which release the work should be done?

No, I don't have any kind of projection yet on when it would be finished.  I got busy at work for awhile and wasn't able to work on the libsexy widgets.  But I've recently started working on SexyIconEntry again and will hopefully have that finished soon, and then I can work on SexyUrlLabel.

Got it. Thanks for your work:-)

We need this feature too (by example something like a tooltip with documentation and a link for the main reference like eclipse do with the documentation popup)

Created attachment 133994 [details] [review]
fairly complete patch

Here is a patch that goes beyond what SexyUrlLabel does. 
It supports links like this:

Bla bla <a href="http://www.gtk.org: title="Our website">GTK+</a> bla.

Stuff that I've added:

- titles are turned into tooltips
- keep track of visited links
- default handler uses gtk_show_uri
- link context menu can be added to using ::populate-popup
- keybindings for 'open link' (hit enter while in a link) and 'copy link' (hit ctrl-c while in a link)
- keynav: can tab through links, the 'active' link gets a focus rectangle
- keynav: can open context menu with the menu key
- api: gtk_label_get_current_uri() for use in signal handlers


Left to do:
- consider an extension mechanism for pango markup instead of the somewhat gross pre-parsing/rewriting approach in this patch
- avoid recalculating everything just to update link colors
- when copying a url to the clipboard, support text/uri-list 
- a11y considerations other than keynav

Created attachment 134037 [details] [review]
minor cleanups

I've committed a substantially rewritten version of this patch.