Kickoff of some code in Exo that is now provided by gtk/glib. exo_gtk_object_ref_sink (g_object_ref_sink). ExoEllipsizedLabel has no additional functionality over GtkLabel. exo_intern_string (g_intern_string) exo_intern_static_string (g_intern_static_string) Maybe drop ExoXsessionClient and work towards 1 implementation in libxfce4ui (private, for the time being).
EXO_PARAM_* is also a possible candidate, but because it's a define i hardly care.
It also looks like GChecksum provides all the functionality of exo_md5.
I'd leave ExoXsessionClient, since it provides something a bit different from what we're gonna do in 4ui. Don't feel very strongly about it, though. The X11R5 stuff is kinda lame, anyway.
Then we should discuss what the GObject api in 4ui will look like, if we have that sorted you, then we can make a good decision whether we leave ExoXsessionClient in or not. I've started bug #5672 for the session discussion in 4ui.
I'd suggest to keep the xsession client. It's easy, (mostly) bug free and only a few lines of code.
I've looked through the code and together with Nick's suggestions, this is what I think makes sense: Definitely remove: - exo_gtk_object_ref_sink (g_object_ref_sink) - ExoEllipsizedLabel (GtkLabel) - exo_intern_string (g_intern_string) - exo_intern_static_string (g_intern_static_string) - exo_md5_*, ExoMd5Digest (GChecksum) - exo_gtk_radio_action_set_current_value (gtk_radio_action_set_current_value) - ExoPangoEllipsizeMode (deprecated already) Maybe remove: - EXO_PARAM_READABLE, EXO_PARAM_WRITABLE, EXO_PARAM_READWRITE Probably leave in place: - ExoXsessionClient I'd also suggest we remove all the ifdefs dealing with old versions of GLib, GTK+ and others.
The EXO_PARAM_ don't take any space and are used in a number of places, so for the sake of less work(tm) we should keep them.
(In reply to comment #7) > The EXO_PARAM_ don't take any space and are used in a number of places, so for > the sake of less work(tm) we should keep them. Yep, sounds good.
FYI, exo_str_is_equal could technically be replaced by g_strcmp0, but I did a benchmark some time ago and it was a bit faster, so I think we should keep it. exo_noop_true/false also have gtk_true/false, but they complete the other noop functions and most likely they are bug free ;-), so not a big deal imho.
Update: I've removed exo_gtk_object_ref_sink() and exo_gtk_radio_action_set_current_value() in the 'versioning-0.3-to-1' branch of exo and updated the 'switch-to-exo-1' branches of all other core components.
Working on it, so assigning this one to me.
I've also removed ExoEllipsizedLabel now. Couldn't find any core component still using it.
Everything I listed under "definitely removed" is now deleted in the 'versioning-0.3-to-1' branch.
It looks like there are a few more deprecated functions which we should remove: - exo_icon_view_{get,set}_text_column() - exo_icon_view_{get,set}_markup_column() - exo_icon_view_{get,set}_pixbuf_column() Anything else?
There are some GTK_CHECK_VERSION code block that could be dropped, but that's not really api related. For now I can't think of anything else.
Ok, good. I'm thinking about going through the ExoJob and ExoSimpleJob API once again to see if it can be improved before making it publically available. I guess we can already merge the exo-1 changes in all components now, and then I'd love to do an exo release 0.3.102 release in the next couple of days.
I think we can move the _ExoBinding* structures in the C file, every other structure/object seems to be "sealed", but maybe you can look over this too, so we don't expose any private stuff in the headers.
Mm I missed ExoMountPoint, used by thunar-vfs and thunar-volman. I've no idea if it's still useful or it requires sealing. Leave that up to you Jannis.
By quickly searching over the page, I had like to add to the list: - ExoCellRendererEllipsizedText - ExoCellRendererIcon => I don't know exactly what the follow-state is good for there - ExoTreeView => not sure, as it provides facilities to activate rows on timeouts - exo_url_show* - EXO_URL_ERROR_NOT_SUPPORTED => gtk_show_uri since 2.14 Regarding the xsession-client code, it is a very simple and dummy implementation to use. If the new implementation covers something more difficult it could be worth to keep this one IMO.
(In reply to comment #19) > By quickly searching over the page, I had like to add to the list: > > - ExoCellRendererEllipsizedText > - ExoCellRendererIcon > => I don't know exactly what the follow-state is good for there Follow-state 'highlights' the selected item, so rounded borders around the text and a glow in the icon. Icon is supported in gtk, but this is pretty ugly IIRC, label is not supported yet. > - ExoTreeView > => not sure, as it provides facilities to activate rows on timeouts Single click is also not supported in gtk yet. > - exo_url_show* > - EXO_URL_ERROR_NOT_SUPPORTED > => gtk_show_uri since 2.14 Possible candidate, but since it uses the GAppInfo stuff internally we should make sure the exo-preferred-applications settings work with gtk (would be nice anyways). If it does we could drop exo-url.{c,h} and move the exo_url_about_dialog_hook to the gtk extensions files.
(In reply to comment #20) > (In reply to comment #19) > > - exo_url_show* > > - EXO_URL_ERROR_NOT_SUPPORTED > > => gtk_show_uri since 2.14 > > Possible candidate, but since it uses the GAppInfo stuff internally we should > make sure the exo-preferred-applications settings work with gtk (would be nice > anyways). If it does we could drop exo-url.{c,h} and move the > exo_url_about_dialog_hook to the gtk extensions files. exo-open/exourlshow uses thunar to show a directory. gappinfo/gtkshowuri uses (I guess) the first matched mimetype which in my case ends to be konqueror... not a sane choice under an Xfce session. I will digg more about this, but all in all, I think that the preferred applications won't be followed by applications using gtkshowuri.
Tried it here a bit and it does not launch anything at all, returns this error "** Message: failed: Automount failed: Failed to execute child process "/usr/lib/gvfs/gvfsd-http" (No such file or directory)" or I get this error "GConf Error: Bad key or directory name: "/desktop/gnome/url-handlers/http:///command": Can't have two slashes '/' in a row". To make this work properly will consume a lot of time, so I'd say stick with the current code since we only want to cleanup and not completely break behaviours here.
(In reply to comment #22) > To make this work properly will consume a lot of time, so I'd say stick with > the current code since we only want to cleanup and not completely break > behaviours here. Yeah, we'd need to write a GIO extension that uses the G_DESKTOP_APP_INFO_LOOKUP_EXTENSION point and handles http uris, setting the default to use exo-open. It's not super hard, but... it's work. And in the end we'd probably install it with exo anyway, so using gtk_show_uri() instead of exo's equivalent wouldn't really drop the exo dependency for an app just using that function (though it would make it a soft runtime dep that could be fulfilled with something else...).
Closing bug, made a separate bug for supporting gtk_show_uri(), see bug #5687. The extended cell render and treeview in exo cannot be replaced by the gtk versions, so lets wait until gtk picks this up.