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 787242 - Wrap gtk_show_uri_on_window(), e.g. as a member of Gtk::Window
Wrap gtk_show_uri_on_window(), e.g. as a member of Gtk::Window
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2017-09-04 10:44 UTC by Daniel Boles
Modified: 2018-11-04 18:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Window: Wrap gtk_show_uri_on_window() (901 bytes, patch)
2017-09-06 21:21 UTC, Daniel Boles
none Details | Review
Window: Wrap gtk_show_uri_on_window() (902 bytes, patch)
2017-09-12 20:21 UTC, Daniel Boles
committed Details | Review

Description Daniel Boles 2017-09-04 10:44:10 UTC
I've not found a gtkmm wrapper for gtk_show_uri_on_window, so I need to do e.g.

        gtk_show_uri_on_window(GTK_WINDOW( m_window.gobj() ), path.c_str(),
                               GDK_CURRENT_TIME, NULL);

It'd be handy if this was wrapped, and the most sensible place seems to be as a member function of Gtk::Window, e.g.

        my_window.show_uri(path, GDK_CURRENT_TIME); // may throw

There's also gtk_show_uri(), which would be a member of Gdk::Screen, but as that's deprecated, we probably shouldn't expend time in a way that'd encourage its use.
Comment 1 Murray Cumming 2017-09-04 13:18:23 UTC
I agree. That would be good. Thanks.
Comment 2 Daniel Boles 2017-09-06 19:22:53 UTC
I presume that, while the GTK+ version takes an optional GError and also returns TRUE/FALSE on success/failure, we would return void and let the user check for exceptions if they care?
Comment 3 Daniel Boles 2017-09-06 19:31:51 UTC
Also, regarding the timestamp argument, I presume that:
 * you'd prefer to express the type as guint32, rather than C++'s std::uint_32_t;
 * we shouldn't default it to GDK_CURRENT_TIME, as "ideally" it shouldn't be that
Comment 4 Daniel Boles 2017-09-06 20:19:17 UTC
(In reply to Daniel Boles from comment #2)
> I presume that, while the GTK+ version takes an optional GError and also
> returns TRUE/FALSE on success/failure, we would return void and let the user
> check for exceptions if they care?

Looking around, we seem to just continue returning bool anyway. I guess that makes sense, providing another/simpler way to check for errors.
Comment 5 Daniel Boles 2017-09-06 21:21:36 UTC
Created attachment 359315 [details] [review]
Window: Wrap gtk_show_uri_on_window()

This is a very useful function that gtkmm did not wrap until now.

--

Very simple, of course.

I didn’t make this const or spend much time thinking about whether we should.
But eventually this can lead to e.g. another window getting shown transient-for
this one, so probably const would be wrong anyway.
Comment 6 Kjell Ahlstedt 2017-09-07 07:50:28 UTC
> Looking around, we seem to just continue returning bool anyway. I guess that
> makes sense, providing another/simpler way to check for errors.

It's true that many glibmm and gtkmm functions both throw an exception and
return a bool that shows if it throws an exception. It does not make sense.
You can't ignore an exception. If you don't catch it, the program will
terminate. You will never see a false return value.

Some C++ functions replace the gboolean return value with void.
Examples: Gtk::RecentManager::move_item(), Gtk::RecentManager::remove_item(),
Gtk::Window::set_icon_from_file(). There are many more examples in glibmm/gio.
Comment 7 Daniel Boles 2017-09-07 08:49:27 UTC
Right, yeah. Should we then try to move away from the pattern of returning that bool? (Assuming it always reflects whether the GError was set, rather than being able to reflect other results too.)
Comment 8 Kjell Ahlstedt 2017-09-07 11:53:20 UTC
Yes, when a gboolean return value is just an alternative to a GError**
parameter, IMO the corresponding C++ function should return void.
Comment 9 Daniel Boles 2017-09-12 20:21:06 UTC
Created attachment 359664 [details] [review]
Window: Wrap gtk_show_uri_on_window()

This is a very useful function that gtkmm did not wrap until now.


--

Return void instead of bool.

--

Shall we open a new bug to ponder removing such bool return values for other
functions where they offer nothing?
Comment 10 Murray Cumming 2017-09-13 08:37:28 UTC
Review of attachment 359664 [details] [review]:

Looks good.
Comment 11 Murray Cumming 2017-09-13 08:39:48 UTC
> Shall we open a new bug to ponder removing such bool return values for other
functions where they offer nothing?

Please feel free to just make those changes in git master.
Comment 12 Daniel Boles 2017-09-14 17:51:57 UTC
(In reply to Murray Cumming from comment #10)
> Review of attachment 359664 [details] [review] [review]:
> 
> Looks good.

Thanks. Just to check, this is OK for gtkmm-3-22, I presume?
Comment 13 Murray Cumming 2017-09-14 19:28:46 UTC
I'd rather not, if we can avoid it, please. That would be our first API addition (though not our first deprecation) in the 3.22 branch. Of course, that problem would be solved if there were ever a GTK+ 3.24.
Comment 14 Daniel Boles 2017-09-14 19:30:23 UTC
I thought you concluded that since GTK+ have no plans to release that version, reasonable additions could be done in gtkmm-3-22:

> On 5 April 2017 at 15:00, Murray Cumming <murrayc@murrayc.com> wrote:
> > On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote:
> > > I agree with Diether and Daniel: Let's do as gtk+ does, even
> > though
> > > they break the rules.
> >
> > OK. Then I don't object anymore. Thanks for being patient. Feel
> > free to
> > add API in the gtkmm-3-22 branch:

:-)
Comment 15 Murray Cumming 2017-09-14 21:17:43 UTC
I have just replied that old email on gtkmm-list to explain.
Comment 16 Daniel Boles 2017-09-14 21:56:56 UTC
to master for now

Attachment 359664 [details] pushed as cc94bde - Window: Wrap gtk_show_uri_on_window()
Comment 17 Daniel Boles 2017-09-14 21:58:41 UTC
I didn't specifically mean to close, but I guess it'll do; we can reopen if we ever start down the slippery slope of adding new, or more accurately missing, API.
Comment 18 Daniel Boles 2017-09-21 10:39:25 UTC
(In reply to Kjell Ahlstedt from comment #8)
> Yes, when a gboolean return value is just an alternative to a GError**
> parameter, IMO the corresponding C++ function should return void.

I've opened a bug about the fact that, when replacing this or any other return value with a void, the generated documentation still includes a Returns block with the C description of the ignored return value: Bug 787978
Comment 19 Kjell Ahlstedt 2018-11-04 16:24:24 UTC
I have pushed Daniel's patch, adding Gtk::Window::show_uri(), to the gtkmm-3-24 branch.
Comment 20 Daniel Boles 2018-11-04 18:14:31 UTC
Thanks!