After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 314808 - port GnomeHref to gtk
port GnomeHref to gtk
Product: gtk+
Classification: Platform
Component: Widget: Other
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2005-08-30 01:01 UTC by Emmanuele Bassi (:ebassi)
Modified: 2011-02-04 16:10 UTC
See Also:
GNOME target: ---
GNOME version: ---

proposed api for EggLinkButton (2.69 KB, text/plain)
2005-08-30 01:02 UTC, Emmanuele Bassi (:ebassi)
revised API for EggLinkButton (3.21 KB, text/plain)
2005-09-04 00:41 UTC, Emmanuele Bassi (:ebassi)
EggLinkButton header (3.16 KB, text/plain)
2005-09-23 18:27 UTC, Emmanuele Bassi (:ebassi)
EggLinkButton implementation (16.41 KB, text/plain)
2005-09-23 18:28 UTC, Emmanuele Bassi (:ebassi)
EggLinkButton screenshot (37.79 KB, image/png)
2005-09-23 18:32 UTC, Emmanuele Bassi (:ebassi)
EggLinkButton screenshot (hover) (28.12 KB, image/png)
2005-09-23 18:33 UTC, Emmanuele Bassi (:ebassi)
GtkLinkButton header (2.60 KB, text/plain)
2006-01-21 14:03 UTC, Emmanuele Bassi (:ebassi)
GtkLinkButton implementation (14.73 KB, text/plain)
2006-01-21 14:03 UTC, Emmanuele Bassi (:ebassi)
GtkLinkButton implementation (correct) (14.65 KB, text/plain)
2006-01-21 14:06 UTC, Emmanuele Bassi (:ebassi)

Description Emmanuele Bassi (:ebassi) 2005-08-30 01:01:52 UTC
Please describe the problem:
tracer bug for porting the GnomeHref widget from libgnomeui into gtk+.

Steps to reproduce:

Actual results:

Expected results:

Does this happen every time?

Other information:
Comment 1 Emmanuele Bassi (:ebassi) 2005-08-30 01:02:35 UTC
Created attachment 51534 [details]
proposed api for EggLinkButton
Comment 2 Emmanuele Bassi (:ebassi) 2005-08-30 01:05:04 UTC
the EggLinkButton is a replacement for GnomeHref.

basically, is the same widget: a button (with no relief) that has a "uri" property.

since we don't know the handler for the uri, we can't spawn a process or use
functions like gnome_url_show(); the action on user click will be entirely
demanded to the user of this widget.
Comment 3 Paolo Maggi 2005-08-30 09:40:56 UTC
What is the "active" property used for?

I think you should add a function similar to gtk_about_dialog_set_url_hook to
set a global handler for the click action.

Probably the new_with_label function should take also a url parameter.

I think you should add a new_with_mnemonic function too.

In the wiki page you wrote that URL should be utf-8 encoded. I do not agree, it
should be a valid (properly escaped) URL (we should not promote the use of
broken malformed URL).
Comment 4 Emmanuele Bassi (:ebassi) 2005-08-30 10:53:29 UTC
1. the "active" property would enable a "off-line" status; if we just make the
widget unsensitive, no tooltips and no events are propagated, so we can't - say
- add a tooltip telling the user "we are off-line, so the link is disabled".
maybe is overengineering, but I think that could be useful.

2. uhm, isn't the GtkButton::clicked signal enough? the about dialog doesn't
expose the widgets used to show hyperlinks, but in this case the widget is
obviously ther.

3. isn't there?

GtkWidget *egg_link_button_new_with_label (const gchar *uri, const gchar *label);

4. yep, you're right about the new_with_mnemonic ctor, I'll add it.

5. okay, I'll promote the URI to UTF-8 in case no label has been passed.
Comment 5 Paolo Maggi 2005-08-30 11:07:43 UTC
Note that label is different from URL

You can have a button with label "Gnome Website" associated to the

I will reply to the other points later.
Comment 6 Matthias Clasen 2005-08-30 14:02:21 UTC
So, before spending too much more work on polishing here, can we please first 
go over gnome cvs and find the actual uses o GnomeHref ? No point porting
such special-purpose widgets, if they are not widely used.
Comment 7 Paolo Maggi 2005-08-30 14:05:51 UTC
1. I don't have a strong opinion on this. It may be an useful feature, but I'm
not so sure. Why do you need the tooltip for the button if you will not be able
to use it?

2. In most cases the programmer will connect the clicked signal of all the href
buttons to the same function or to different copies of the same function. I
think we could simplify his/her life adding a way to autoconnect the click
signals of all the href buttons to a given function.

3. ops... sorry (sorry also for comment #5)

5. You will have to use a function similar to gnome_vfs_format_uri_for_display
(I don't remember if glib has such a function).
Comment 8 Emmanuele Bassi (:ebassi) 2005-08-30 18:06:43 UTC
comment #6: AFAIR, it's used by rhythmbox and another couple of apps. but we
could also use it internally in the GtkAboutDialog widget, instead on relying on
a custom implementation of a hyperlink widget.

comment #7: a state property different from the usual "sensitive" property
should be used because the action taken by the button might not be available in
a manner not dependent on the state of the widget itself.

as for the hook, I think you're right.
Comment 9 Emmanuele Bassi (:ebassi) 2005-09-04 00:41:59 UTC
Created attachment 51774 [details]
revised API for EggLinkButton

added the hook function and the new_with_mnemonic ctor.
Comment 10 Paolo Maggi 2005-09-06 10:35:36 UTC
The hook function must be global.
There is no point in addding a per-button hook function (you can connect to the

As said by Jonathan in, may
be we should consider adding <a href=".."></a> support to GtkLabel.
Comment 11 Emmanuele Bassi (:ebassi) 2005-09-06 11:11:53 UTC
yep, it's my mistake: I've sent a wrong header file. my local tree is correct.

as for adding anchors to the markup used by GtkLabel, I'll investigate it, even
though a separate widget might still be a better idea for the common case where
GnomeHref was used.
Comment 12 Emmanuele Bassi (:ebassi) 2005-09-23 18:25:06 UTC
Here's the initial implementation, replacing GnomeHref functionalities.

Since Paolo requested a ctor with a mnemonic label, I have had to remove the
underline to the widget's label; the underlined link appears only when hovering
with the pointer.

Possible enhancements:
* different colors for the "link:hover" and "link:active" states;
* a popup menu, showing the "copy link to clipboard" and "launch link in
browser" items;
Comment 13 Emmanuele Bassi (:ebassi) 2005-09-23 18:27:31 UTC
Created attachment 52566 [details]
EggLinkButton header
Comment 14 Emmanuele Bassi (:ebassi) 2005-09-23 18:28:02 UTC
Created attachment 52567 [details]
EggLinkButton implementation
Comment 15 Emmanuele Bassi (:ebassi) 2005-09-23 18:32:35 UTC
Created attachment 52568 [details]
EggLinkButton screenshot
Comment 16 Emmanuele Bassi (:ebassi) 2005-09-23 18:33:16 UTC
Created attachment 52569 [details]
EggLinkButton screenshot (hover)
Comment 17 Christian Persch 2005-10-03 11:34:37 UTC
Just a note: bug 113649 adds thevisited-link-color style property while you name
this link-active-color; also this patch adds link-hover-color which is missing
from the patch in bug 113649 and should probably be added there.
Comment 18 Mathias Hasselmann (IRC: tbf) 2006-01-19 10:27:02 UTC
Wondering if it would not be more usefull to extend Pango's markup language to support hyperlinks. Would be nice to have hyperlinks embedded into GtkLabel captions.
Comment 19 Matthias Clasen 2006-01-20 17:21:23 UTC
Ok, taking a detailed look now; I still think this is a fairly special case
widget, but since it is very small, we may as well add it. But lets not 
overdo it.

- I don't think a separate hover color is really needed. You already get the
  button prelighting on hover, which is more than enough to make it clear that
  this is an active ui element.

- I don't like the active property much; we have the problem of tooltips on 
  insensitive widgets everywhere, there is no need to special case it here.

- I don't think the hook function is necessary at all. It is necessary for 
  the about dialog, since there is no way to connect to a signal, but for
  the link button, just connecting to the clicked signal should work fine.

- I don't like the mnemonic addition, and in particular the fact that it forces
  us to drop the underlining. Underlinedness is a big part of what makes 
  links links, visually, so I'd rather see us use underlines all the time,
  and not have mnemonics (GnomeHRef does not have mnemonics either, does it ?)

- It might be nice to support Copy and paste of the url too, if you allow

- Please use G_DEFINE_TYPE, and add "Since: 2.10" where appropriate
Comment 20 Emmanuele Bassi (:ebassi) 2006-01-21 14:02:25 UTC
new attempt at the LinkButton, after Matthias' review.

- I've removed the "underline on highlight" and the hook function;
- I've added a popup menu with the "copy URL" item which copies the URL to the clipboard;
Comment 21 Emmanuele Bassi (:ebassi) 2006-01-21 14:03:27 UTC
Created attachment 57789 [details]
GtkLinkButton header
Comment 22 Emmanuele Bassi (:ebassi) 2006-01-21 14:03:54 UTC
Created attachment 57790 [details]
GtkLinkButton implementation
Comment 23 Emmanuele Bassi (:ebassi) 2006-01-21 14:06:47 UTC
Created attachment 57791 [details]
GtkLinkButton implementation (correct)

correct version
Comment 24 Matthias Clasen 2006-01-24 03:40:44 UTC
I made it use the new link-color and visited-link-color
style properties, and readded the underlining.

2006-01-23  Matthias Clasen  <>

	Add GtkLinkButton, a port of GnomeHRef.  (#314808, Emmanuele Bassi)
	* gtk/gtklinkbutton.h: 
	* gtk/gtklinkbutton.c: New files.

	* gtk/gtk.h:
	* gtk/gtk.symbols: 
	* gtk/ Glue.

	* gtk/gtkaboutdialog.c: Use GtkLinkButton.