Since Thunar itself now uses Gio and Udev for device handling, the places plugin should follow and use the same framework. This would make the dependency on ThunarVFS obsolete and would allow me to get rid of HAL for good.
*** Bug 6674 has been marked as a duplicate of this bug. ***
Yes, you're absolutely right, places needs to be ported over. Let me know if you want to work on this; my time for the project has been quite limited lately.
Damn, bugzilla (and/or me) really has searches issues. Sorry for duplicate. No I don't really have time to port it (I barely have time to maintain Xfce stuff these days) but thought it'd be nice to track it, except I didn't see it was already tracked. For people interested, it might be worth giving some infos about the current state (how it is done at the moment) and how it should be done in a Gio world (the latter needing info from people aware, maybe Jannis could give some doc?) Cheers and thanks for your work.
I haven't looked at the code yet but I remember the plugin vaguely and it should be as simple as replacing the portions of code related to thunar-vfs with usages of GIO. I don't think there's anything special (like integrating udev) that needs to be taken care of.
*** Bug 6966 has been marked as a duplicate of this bug. ***
I use places myself, so I'll be sure to get to this eventually. But if someone can contribute a patch before I get there, that would be great.
Created attachment 3497 port to gio Here is the patch :) Please check and test, this patch is a shameless rip from xfdesktop.
(In reply to comment #7) > Created attachment 3497 > port to gio > > Here is the patch :) > Please check and test, this patch is a shameless rip from xfdesktop. What to apply this patch to? Neither the latest 1.2.0 nor the latest git seems to work. Here’s the output from trying to patch the git version: patching file config.h.in Hunk #2 succeeded at 67 with fuzz 2 (offset 4 lines). Hunk #3 succeeded at 92 with fuzz 2 (offset 7 lines). patching file configure.in Hunk #1 FAILED at 15. 1 out of 1 hunk FAILED -- saving rejects to file configure.in.rej patching file panel-plugin/Makefile.am Hunk #3 FAILED at 47. 1 out of 3 hunks FAILED -- saving rejects to file panel-plugin/Makefile.am.rej patching file panel-plugin/model.h patching file panel-plugin/model_system.c patching file panel-plugin/model_user.c patching file panel-plugin/model_volumes.c Hunk #5 FAILED at 405. Hunk #6 succeeded at 420 (offset 3 lines). Hunk #7 succeeded at 474 (offset 3 lines). Hunk #8 succeeded at 484 (offset 3 lines). Hunk #9 succeeded at 518 (offset 3 lines). Hunk #10 succeeded at 540 (offset 3 lines). Hunk #11 succeeded at 548 (offset 3 lines). 1 out of 11 hunks FAILED -- saving rejects to file panel-plugin/model_volumes.c.rej patching file panel-plugin/model_volumes_notify.c patching file panel-plugin/model_volumes_notify.h patching file panel-plugin/view.c Hunk #1 succeeded at 59 (offset 2 lines). Hunk #2 succeeded at 69 (offset 2 lines). Hunk #3 succeeded at 458 (offset 2 lines). Hunk #4 FAILED at 541. Hunk #5 succeeded at 950 (offset -10 lines). 1 out of 5 hunks FAILED -- saving rejects to file panel-plugin/view.c.rej patching file panel-plugin/xfce46-compat.c patching file panel-plugin/xfce46-compat.h
Created attachment 3507 patch for clean 1.2.0 This patch applies to clean 1.2.0 sources.
(In reply to comment #8) > (In reply to comment #7) > > Created attachment 3497 > > port to gio > > > > Here is the patch :) > > Please check and test, this patch is a shameless rip from xfdesktop. > > What to apply this patch to? Neither the latest 1.2.0 nor the latest git seems > to work. Here’s the output from trying to patch the git version: > It applies to 1.2.0 on top of exo-1 (id:5754) and libxfce4ui (id:7317) patches. I added a patch for clean 1.2.0 sources.
Would you guys be interested in a complete rewrite instead? (using C++ and gtkmm/glibmm)
(In reply to comment #11) > Would you guys be interested in a complete rewrite instead? (using C++ and > gtkmm/glibmm) Definitely not.
Let's put it this way: we don't use C++ anywhere in Xfce core, so if it can be avoided, extensions should be written without additional dependencies/libraries to be loaded.
Ok. I totally get Jannis Pohlmann's reasons. But from Yves-Alexis Perez's reply I have to ask this. Is the Xfce's team stance against C++(in general) the same as the Gnome's/Gtk's team? (not exactly hating it but not actively supporting it etc etc)
(In reply to comment #14) > Ok. I totally get Jannis Pohlmann's reasons. But from Yves-Alexis Perez's reply > I have to ask this. Is the Xfce's team stance against C++(in general) the same > as the Gnome's/Gtk's team? (not exactly hating it but not actively supporting > it etc etc) (note that I'm not in the Xfce team, not as an active developer at least, I'm a Debian maintainer) As Jannis said, the whole Xfce stack uses C/GTK+. C++ and Gtkmm looks to me more like a cludge. Personally, I'm really not a huge fan of C++, but there are people using Vala, in case you'd be interested.
We evenhave our own GLib/GTK+ C++ bindings but they are not really actively maintained, I think, and they are not used anywhere. We also don't use glibmm/gtkmm anywhere as it makes little sense for us. The benefit of C++ over C is rather small overall.
I'd love to continue this but I don't want to pollute the bug report. For now, I hope that the patch gets finally in git. It seems to work fine in Debian. But before that please clean up the code that is related to this report of mine: https://bugzilla.xfce.org/show_bug.cgi?id=7666
Mass-reassign all bugs from florian@ to goodies-dev@, thanks for the maintenance work! (and sorry for the bugmail spam..)