Migrate Caja to GtkApplication

[flexiondotorg]

Debian has raised the following bug:

• caja - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827234

This MATE component needs migrating to GtkApplication:

• https://developer.gnome.org/gtk3/3.20/gtk-migrating-unique-GtkApplication.html

[lukefromdc]

I have done some basic work with this, sucessfully running Caja in GtkApplication windows and using GtkApplication to hold it open as in Nautilus and Nemo. This might only be the beginning though as I find references to "_unique" all over the code in a total of 23 files. This WIP branch shows what I've gotten so far, based on Master 7-11-2016:

https://github.com/lukefromdc/caja/tree/GtkApplication-WIP

Again, it looks like this is barely the start of it but it does build and run over GTK 3.21. No help for the GTK 3.21.3 desktop issue but that is no surprise because Nemo has that issue to and uses GtkApplication already.

One issue did arise, not sure why: Cannot run Caja as root (at least not in normal MATE session), possibly due to GtkApplication treating them as two attempts to run as though two instances in same user? Like I said, this is rough and a starting point only,

[raveit65]

Cool that you working on it.
I will test it, maybe you find some help in early nautilus git?

[raveit65]

Btw. there are more applications which needs to be ported, ie. mate-power-manager.
I start to work on it but i wasn't successful the last day.
Unfortunately g-p-m prefs from gnome was moved to control-center before this port was finished in gnome git.

[lukefromdc]

I'll need help understanding what libunique is doing with some of that
"unique message" sort of stuff

On 7/12/2016 at 5:09 AM, "raveit65" notifications@github.com wrote:

Cool that you working on it.
I will test it, maybe you find some help in early nautilus git?

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
231981995

[lukefromdc]

Here's what I'm getting right now when trying to run as root, looks like an issue of something that is still using libunique and needs to be ported over. Keep in mind, ALL of the file managers get Dbus issues when running as root over a non-root session-and Nemo segfaults when run under su in a non-root X session. I need my file managers to work as root for many reasons:

sudo caja:

(caja:10930): GLib-GObject-WARNING **: gsignal.c:2635: instance '0x13d8960' has no handler with id '75'

(caja:10930): GLib-CRITICAL **: Source ID 79 was not found when attempting to remove it

(caja:10930): GLib-CRITICAL **: Source ID 80 was not found when attempting to remove it

(caja:10930): GLib-CRITICAL **: Source ID 81 was not found when attempting to remove it

(caja:10930): Eel-WARNING **: "caja-directory.c: directories" hash table still has 1 element at quit time
luke@ubuntu:~/Desktop/Development/MATE_Development_Work/caja_1.15.1+GtkApplication$ 

su
caja:

(caja:11250): EggSMClient-WARNING **: Failed to connect to the session manager: None of the authentication protocols specified are supported


(caja:11250): Unique-GDBus-WARNING **: Unable to open a connection to the session bus: The connection is closed

(caja:11250): GLib-GIO-CRITICAL **: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Segmentation fault

[lukefromdc]

In digging through old Nautilus commit I found references to a "major refactoring" needed to fully adapt to the use of GtkApplication. That sort of work would be quite beyond me.

[raveit65]

The first block of warnings i see always when i run caja as root.

(caja:11250): EggSMClient-WARNING **: Failed to connect to the session manager: None of the authentication protocols specified are supported

This is because no session-manager is running for the root account.
Not sure about next warning, but it seems related to missing session-manager.

(caja:11250): GLib-GIO-CRITICAL **: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Segmentation fault

This seems to be related. You can try run caja with gdb to find out at which place caja segfault.

In digging through old Nautilus commit I found references to a "major refactoring" needed to fully adapt to the use of GtkApplication.

Which commit is this?

[lukefromdc]

Segfaults are only with "su" and are shared by Nemo. I'm getting some
kind of quit without segfault when using "sudo," will see if something is
causing it to exit.

On 7/12/2016 at 3:49 PM, "raveit65" notifications@github.com wrote:

The first block of warnings i see always when i run caja as root.

(caja:11250): EggSMClient-WARNING **: Failed to connect to the 
session manager: None of the authentication protocols specified 
are supported

This is because no session-manager is running for the root account.
Not sure about next warning, but it seems related to missing
session-manager.

(caja:11250): GLib-GIO-CRITICAL **: 
g_dbus_connection_call_sync_internal: assertion 
'G_IS_DBUS_CONNECTION (connection)' failed
Segmentation fault

This seems to be related. You can try run caja with gdb to find
out at which place caja segfault.

In digging through old Nautilus commit I found references to a
"major refactoring" needed to fully adapt to the use of
GtkApplication.
Which commit is this?

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
232158463

[lukefromdc]

I just found that replacing the original
/* Keep the main event loop alive as long as the window exists /
#if GTK_CHECK_VERSION(3, 0, 0)
/ FIXME: port to GtkApplication with GTK3 */
//gtk_quit_add_destroy (1, GTK_WIDGET (window));
caja_main_event_loop_register (GTK_WIDGET (window));
#else
gtk_quit_add_destroy (1, GTK_OBJECT (window));
caja_main_event_loop_register (GTK_OBJECT (window));
#endif
}`

with

/* Keep the main event loop alive as long as the window exists */
#if !GTK_CHECK_VERSION(3, 0, 0)
gtk_quit_add_destroy (1, GTK_OBJECT (window));
caja_main_event_loop_register (GTK_OBJECT (window));
#endif
}`

is enough to trigger the immediate exit of the root instance on "sudo caja," this is the exit without the segfault.

[lukefromdc]

Reverted the removal of "caja_main_event_loop_register" in caja-window.c, now it works fine as root and seems to be indistinguishable in behavior from Master. Still a hell of a lot of instances of libunique in this but it seems to be fine with running in a GtkApplicationWindow

[lukefromdc]

I just managed to get Caja running both normally and as root with libunique excluded entirely. Lost the special icons for home, trash, and computer (network not selected) due to one of the _unique_message_data functions apparently being responsible for fetching their URI's. Looks like it will be far easier to fix this with new code than old nautilus commits due to so many differences.

Had to make a new GTK3-only branch due to build failures with the #if selectors in caja-application.h for some wierd reason. This also allows a search for "unique" in the code to verify it is gone. All other files containing this in code refer to functions in Eel and not to libunique it seems, and I didn't find any other files that used an include for libunique.

I tried to apply
GNOME/nautilus@b03b081
"application: make NautilusApplication a GtkApplication subclass"
to Caja with the necessary changes, had to modify a couple more files to get the build to complete, but got segfaults on attempts to run that mess. The GNOME commit was radical changes all the way through and something just didn't work.

I've apparently got libunique out of this in a far simpler way, in fact even did a build of my just commited code with all references to libunique removed from configure.ac. I just need a way to get back the trash, home, and computer icons. Don't know if this is good usage of GtkApplication though so this one REALLY would need that code review.

[raveit65]

@monsta @XRevan86
Please can you do a code review there and help

[raveit65]

maybe @clefebvre can help too

[sc0w]

I think is better drop all gtk 2 old code, before the gtkapplication implementation

[lukefromdc]

https://github.com/lukefromdc/caja/tree/GtkApplication_Nogtk2_WIP4

Newest branch fixes the special icons on the desktop and extensions, is based on today's master. Problem was very simple: the "finish_startup" function was never being reached as the code to launch it was behind the libunique stuff I removed. I set it to run unconditionally and it works. Everything is on the desktop and navigation windows I expect, CPU use stays down, errors in terminal running root are same as for master. So far no discernable behavior change from this from master at all.

I just built this with the "pathbar" commits also applied and packaged it up for daily use and testing. I could put in a PR now but people were saying they wanted to drop the GTK2 stuf first.

Today's branch does not support GTK2 builds, that was just too complex. Didn't change configure.ac yet to exclude libunique checks but have tested that. It too is too complex for me if GTK2 is retained but very simple for GTK3 only, so I left that alone for now in case we decide to go back and reinstall GTK2 support in this(which could be done, I've done that kind of thing before in mate-panel).

[lukefromdc]

I just found one behavioral change: it's possible by calling Caja from terminal with no arguments to open a second instance of Caja though no ill effects are observed from this. Preventing this was presumably libunique's job and apparently can also be done with GtkApplication, though what I've done does not have that effect.

This being the file manager code review is more important than normal: it would really suck to get MATE 1.16 out the door only to find out 2 months later that some corner case has been eating people's files-and that half of those folks had no backups. Thus changes to make this code more robust, more secure, whatever are more than welcome.

[lukefromdc]

branch rebased for changes in Master as
https://github.com/lukefromdc/caja/tree/gtkapplication-nogtk2-WIP5
Also, it turns out mate-desktop/master can also start a new instance of Caja from terminal by invoking without arguments, this is nothing new so behavior of this branch is identical to master on my machine.

[sc0w]

more documentation about this:

https://wiki.gnome.org/HowDoI/GtkApplication

[raveit65]

I'm just testing your current branch, seems to be OK after a quick test.
I will test next week more as i travel some days.
But i noticed some new build warnings, not really sure because caja produce so much build warning, you can't know if they are old or new.
As this is a massive change it seems to be easier to work on gtk3 only code.
I suggest that we first create a gtk3 branch where we can work on this and other open deprecations.
I know with switching caja to gtk3 we reached a point of no return, than it isn't possible any more to build Mate with gtk2.
On the other side if libunique will be droped in debian than we have no other choice.
@monsta @flexiondotorg @clefebvre
thoughts?
And please take a look in the code for a pre-review.

[lukefromdc]

I'm playing with some of the code for changing the startup coding to
use GtkApplication but this work might defeat me with its complexity.
If it is sucessful it will be an entirely new branch-but I don't know if we
need to bother with that at all. Nemo uses GtkApplication fully and still
has the desktop/GTK 3.21.3 issue so it doesn't fix that.

Checking warnings is best done by comparing build and runtime warnings
of master vs a branch, in that way I found I was getting the same runtime
warnings either way. Right now I have to head out, more later on this.

On 7/15/2016 at 5:43 PM, "raveit65" notifications@github.com wrote:

I'm just testing your current branch, seems to be OK after a quick
test.
I will test next week more as i travel some days.
But i noticed some new build warnings, not really sure because
caja produce so much build warning, you can't know if they are old
or new.
As this is a massive change it seems to be easier to work on gtk3
only code.
I suggest that we first create a gtk3 branch where we can work on
this and other open deprecations.
I know with switching caja to gtk3 we reached a point of no
return, than it isn't possible any more to build Mate with gtk2.
On the other side if libunique will be droped in debian than we
have no other solution.
@monsta @flexiondotorg @clefebvre
thoughts?
And please take a look in the code for a pre-review.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
233077155

[sc0w]

@raveit65 thanks, good choice :)

I need to do that on mate-user-share:

mate-desktop/mate-user-share#38

[lukefromdc]

Nautilus turns out to be a rather ugly mess, using parts of both GtkApplication AND Gapplication. Very hard to apply what they did piecemeal without getting segfaults.
Edit: worst of all, some of the earliest commits may have used code that no longer works

What I've managed to do so far is a minimal removal of the Libunique dependency plus using the GtkApplicationWindow code from the engrampa commits. If this works we could leave that as-is, but one concern I have is the growing number of kludges and workarounds ge get trying to run the treadmill GTK changes are throwing at us.

If it is possible to match what Nautilus (or Nemo forked from Nautilus 3.4) did, then the amount of code divergence is reduced. Not sure if I can make much headway on that though.

There is another, rather radical idea: take the code for say, Nautilus 3.14 which still used the eel-editable-label and will build on current GTK 3.21 or on GTK 3.14 (oldest we are worried about) and back out all the UI changes-get rid of the headerbar, bring back the traditional menubar, toolbar, navigation bar, and the old sidebar. The add back the missing features. Finally replace every instance of "nautiilus" with "caja" in every file. This is almost guaranteed to fix the problems with the GTK 3.21 desktop as well, because that works in Nauitlus 3.14.

EDIT: Starting to wonder if that might actually be easier than what we've been doing-but not easy either, I got got nowhere in 2 hours trying to put the old toolbar back in Nautilus 3.8, the oldest I can build.

[raveit65]

There is another, rather radical idea: take the code for say, Nautilus 3.14 which still used the eel-editable-label and will build on current GTK 3.21 or on GTK 3.14 (oldest we are worried about) and back out all the UI changes-get rid of the headerbar, bring back the traditional menubar, toolbar, navigation bar, and the old sidebar. The add back the missing features. Finally replace every instance of "nautiilus" with "caja" in every file. This is almost guaranteed to fix the problems with the GTK 3.21 desktop as well, because that works in Nauitlus 3.14.

In other report you said nautilus-3.8 does not have the redraw issue, right ?
#575 (comment)
You can to run the gnome-mate-port script on this version or older versions and compile the result against mate, to find out which version is fine.
https://github.com/benpicco/mate-scripts
Note: maybe some rename stuff needs to comment out in script.

In digging through old Nautilus commit I found references to a "major refactoring" needed to fully adapt to the use of GtkApplication.

If you mean the same commits than me, i think we will only lost function which are mostly broken and nobody works on it, eg.

• property-browser.
• spartial-window , not broken but do we need this?
  this will probably allow to do the rest of missing GtkTable --> GtkGrid port
• we will lost some sidebars.

Note, i don't want prefer any solution at the moment, without any of the other core member did a statement.

[lukefromdc]

I hope we can avoid a scratch refork. Since 2.32 Nautilus has been
through repeated file renames and refactors, plus some of the commits
were to deal with changes in Gtk and Gapplication that broke things.

The original MATE documentation lists Caja as being forked from a
tarball of unknown version, making this even harder.

On 7/16/2016 at 4:21 AM, "raveit65" notifications@github.com wrote:

There is another, rather radical idea: take the code for say,
Nautilus 3.14 which still used the eel-editable-label and will
build on current GTK 3.21 or on GTK 3.14 (oldest we are worried
about) and back out all the UI changes-get rid of the headerbar,
bring back the traditional menubar, toolbar, navigation bar, and
the old sidebar. The add back the missing features. Finally
replace every instance of "nautiilus" with "caja" in every file.
This is almost guaranteed to fix the problems with the GTK 3.21
desktop as well, because that works in Nauitlus 3.14.

In other report you said nautilus-3.8 does not have the redraw
issue, right ?
#575 (comment)
229478757
You can to run the gnome-mate-port script on this version or older
versions and compile the result against mate, to find out which
version is fine.
https://github.com/benpicco/mate-scripts
Note: maybe some rename stuff needs to commit out in script.

In digging through old Nautilus commit I found references to a
"major refactoring" needed to fully adapt to the use of
GtkApplication.

If you mean the same commits than me, i think we will only lost
function which are mostly broken and nobody works on it, eg.

• property-browser.
• spartial-window , not broken but do we need this?
  this will probably allow to do the rest of missing GtkTable -->
  GtkGrid port
• we will lost some sidebars.

Note, i don't want prefer any solution at the moment, without any
of the other core member did a statement.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
233119820

[lukefromdc]

After an entire week of work, I finally managed to port the original Nautilus commits for this to Caja.

https://github.com/lukefromdc/caja/tree/GtkApplicationfromNaut_WIP1

GTK 3 only branch presumably. I had to start with the nautilus version of caja-application.c as it was far easier to add back the Caja changes than ever to apply the massive Nautilus commits by hand. This is from the early work GNOME did and has one serious issue at the moment: opens with a window showing, exits if the last window is closed (desktop included). A later commit to fix some ugly session manager issues probably including this didn't build but I wanted to ensure this code did not get away from me after so much work. Other than the close on last window/open with one window showing SM issue it works normally-and I still remember those bugs from Nautilus 2.91.

Based on all of these Nautilus commits, which had to be sequentially applied to build, and the final one to get it to run:

GNOME/nautilus@dc0b129
"application: split SmClient code in its own module."

GNOME/nautilus@b03b081
application: make NautilusApplication a GtkApplication subclass

GNOME/nautilus@a8481ee
main: adapt to GtkApplication changes

GNOME/nautilus@f487966
application: fix interaction with SMCLient (to fix build)

GNOME/nautilus@7500dd4
[src] use new GtkApplication API to handle windows (required for build)

YIELDED:

(caja:2227): GLib-GIO-CRITICAL **: GApplication subclass 'CajaApplication' failed to chain up on ::startup (from start of override function)
and segfault

So apply:

GNOME/nautilus@2d702e1
application: make sure to initialize GTK+ during _startup()

WORKS, but CRASH on closing last window.

EDIT: From this point more Nautilus commits can be applied as needed (and will build)

[lukefromdc]

More Nautilus commits applied to last night's branch, yielding this branch that seems to work fine except that it must be started from a .desktop file and not the session manager (the way Nautilus itself is also now started in GNOME):

https://github.com/lukefromdc/caja/tree/GtkApplicationfromNaut_WIP2

To last night's branch I had to apply everything between
GNOME/nautilus@56dd8bb
application: move other init/cleanup functions in the app class
and
GNOME/nautilus@4882f2a
application: fix some bad interactions with GApplication

that affected the GtkApplication work and had not already been applied on a GTK3 build selector basis.

If you try to start this with the session manager it starts with a navigation window open, and worse the session manager hangs, crashes, and restarts. With a blank filemanager entry in session>required-components and an autostart .desktop file calling caja -n the session and caja seem to function fine except that (like Nautilus in GNOME) there is no auto-restart if Caja is killed.

[raveit65]

3.21.4 is now landed in fedora rawhide, now i can reproduce issues and test fixes.

[raveit65]

Maybe it's possible to start caja like nemo.
nemo-autostart is in /usr/share/applications
linuxmint/nemo@0814498
https://github.com/linuxmint/nemo/blob/master/data/nemo-autostart.desktop.in#L7
And is called via cinnamon session file as 'RequiredComponents'
linuxmint/cinnamon@8e593bf
Not sure if there are more changes needed for usings 'RequiredComponents'.
But i think nemo will auto-restart.
AutostartCondition=GSettings org.nemo.desktop show-desktop-icons
Edit: wrong, this is for autostart.

[raveit65]

To get this working we need to backport changes from early g-s-m.
Started with 'gsm: Move the code filling the autostart apps to gsm-session-fill`
https://git.gnome.org/browse/gnome-session/log/?id=22b1affed9d62ad1ad79806115fea50e511113f8&qt=grep&q=session

[lukefromdc]

I will try that tonight, I am now using that code with a .desktop file to start it.
Will commit an update tonight to bring back command line help which wihout
that fix will crash caja on invocation. Wrote it last night but it was 3AM and i
had to shut down. I am no on the road and can't get to my files until I get home.

On 7/20/2016 at 10:41 AM, "raveit65" notifications@github.com wrote:

Maybe it's possible to start caja like nemo.
nemo-autostart is in /usr/share/applications
linuxmint/nemo@081449869f41277482d588a437
f22c01184d11c5
https://github.com/linuxmint/nemo/blob/master/data/nemo-
autostart.desktop.in#L7
And is called via cinnamon seesion file as 'RequiredComponents'
linuxmint/cinnamon@8e593bfd78c424b126c156
eb1e16e9dbd99e3a48
Not sure if there are more changes needed for usings
'RequiredComponents'.
But i think nemo will auto-restart.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
233970345

[lukefromdc]

Got a sucessful distcheck completion by running mate-distcheck with caja not running-and moving the init_css function back to caja_application_command_line , this time just before creating the other windows. Maybe distcheck was catching a race condition, it was failing to load the css file and stopping on that error until this commit:

lukefromdc@1805c61

[lukefromdc]

Just rebased the GtkApplication branch for 8-10-2016 Master with the desktop fixes:
https://github.com/lukefromdc/caja/tree/dev-GtkApplication
This builds with both GTK2 and GTK3 (though I could only RUN the GTK3 builds over mate with GTK3) and passed distcheck so long as Caja was not running while distcheck was being run.

There remains the issue that it has to be started up the same way Nautilus and Nemo are, by a file in /etc/XDG/autostart. I have not been able to get data/makefile.am to installl that for the life of me, a fix for that and I think this is ready for a PR.

If we don't want to deal with the behavior changes GtkApplication introduces there is another option: cut-and-paste the necessary libunique files directly into Caja and build with it as part of Caja itself. This way Debian can drop it and we still have it. That gives us auto-restart and saved sessions, two features Caja and Nemo don't have.

[raveit65]

I just tested #613
and we lost the auto-restart feature, as only debian dropped libunique why should other distos use a code with a regression?
And why can't debian Mate maintainer not just get ownership for libunique.
As i don't see that debian drop that package in a month, i'm in doubt to use this migaration in this state for 1.16, as this is a regression for all other distros.

[raveit65]

PS: i really miss some comments from debian Mate maintainer here.......

[lukefromdc]

One answer is this: dump this branch entirely and simply drop the
necessary code from libunique directly into Caja. Debian is only
saying they won't be providing libunique, not that nobody else is
allowed to provide it or dump it into cut-n-paste code.

To get back the autostart in GtkApplication exceeds my coding ability
at this point. Over time keeping this as my own branch I can probably
get out any bugs that Nautilus also squashed but not fix the autostart
and session manager interaction. GNOME themselves must have never
been able to make that work right as they dumped it prior to releasing
Nautilus 3.0.

On 8/14/2016 at 4:51 AM, "raveit65" notifications@github.com wrote:

I just tested #613
and we lost the auto-restart feature, as only debian dropped
libunique why should other distos use a code with a regression?
And why can't debian Mate maintainer not just get ownership for
libunique.
As i don't see that debian drop that package in a month, i'm in
doubt to use this migaration in this state for 1.16, as this is a
regression for all other distros.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
239662959

[raveit65]

For me the drop in debian sounds not necessary, as main gtk+ and gnome devs are from RedHat,
and rhel7 is a LTS release which will reach his EOL in June 30, 2024,
Honestly, i can't believe that libunique3 support will be stopped by gtk+/gnome before this date.
So picking up libunique in debian is save.

[lukefromdc]

#613 is so far the only code I've been able to come up with that actually works under a wide variety of conditions, doesn't use libunique, and confines all invocations of caja by one user to a single instance. The only way I can think of now to fix that "caja ." bug is to special case that character on the command line, get the working directory, and open a window there. Still doesn't fix restart though. None of the later Nautilus code seems to work in caja as they have just diverged too far by that point.

[raveit65]

Personal, i would stop working on it at the moment as no one from Mate debian maintainer did answer here. We can leave #613 open.
Best solution is that they pick up libunique at debian.
When in fedora a package get orphan every other packager can catch this package.
I can't believe that debian is so much complicated than fedora.

[muktupavels]

WARNING: Application 'caja.desktop' failed to register before timeout
This is most likely is your problem. At least with gnome-session applications that are not started in Application phase must register with session manager.

If your session manager use org.gnome.SessionManager dbus name then only "register-session" property must be set to TRUE when creating GtkApplication:
https://developer.gnome.org/gtk3/stable/GtkApplication.html#GtkApplication--register-session

Otherwise you must create patch that adds support for MATE session manager in gtk+ or simply add registration code in caja:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkapplication-dbus.c#n149

[raveit65]

@albertsmuktupavels
We switched to use org.gnome.SessionManager dbus name with mate1.12 or so, to improve interacting with other applications.

[muktupavels]

Then this is all you need:
g_object_new (CAJA_TYPE_APPLICATION, "register-session", TRUE, ...);

[lukefromdc]

That WORKS, I just tested it and got clean session startup with functional restart.
I will now revert the startup changes (as in this test) and add this change to the PR.

On 8/15/2016 at 1:42 PM, "Alberts Muktupāvels" notifications@github.com wrote:

Then this is all you need:
g_object_new (CAJA_TYPE_APPLICATION, "register-session", TRUE,
...);

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
239872031

[raveit65]

@albertsmuktupavels
It's really a shame that we work on different projects.

[lukefromdc]

lukefromdc@08c9822
allows Caja with GtkApplication to start the same way it does with libunique and to restart automatically.

[lukefromdc]

https://github.com/lukefromdc/caja/tree/dev-GtkApplication2 has been rebased and that segfault traced to a faulty loop and fixed.

[raveit65]

Just tested both the PR and dev-GtkApplication2.
Caja is controlled by session again and auto-restart works, but i can't start caja with sudo anymore.
On the other side starting caja as root works well, which has never work before.
stacktrace with dev-GtkApplication2 branch and sudo command.

Thread 1 (Thread 0x7f8d50be1a80 (LWP 5405)):
#0  0x00007f8d4bce2936 in __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:173
#1  0x00007f8d4cf9b5d9 in g_str_equal (v1=<optimized out>, v2=v2@entry=0x7f8d4edb7b1d) at ghash.c:1846
        string1 = <optimized out>
        string2 = 0x7f8d4edb7b1d "org.gnome.SessionManager"
#2  0x00007f8d4ed2ae23 in gtk_application_impl_dbus_startup (impl=0x560542ba35a0 [GtkApplicationImplX11], register_session=<optimized out>) at gtkapplication-dbus.c:240
        dbus = 0x560542ba35a0 [GtkApplicationImplX11]
        client_id = 0x560542bc7280 ""
        error = 0x0
        res = 0x0
        same_bus = <optimized out>
        bus_name = <optimized out>
        client_interface = <optimized out>
#3  0x00007f8d4ea43d37 in gtk_application_startup (g_application=<optimized out>) at gtkapplication.c:296
        application = 0x560542b49240 [CajaApplication]
#4  0x0000560540cbcfc1 in caja_application_startup (app=0x560542b49240 [CajaApplication]) at caja-application.c:3003
        self = 0x560542b49240 [CajaApplication]

**CUT**

#8  0x00007f8d4d568102 in g_application_register (application=application@entry=0x560542b49240 [CajaApplication], cancellable=cancellable@entry=0x0, error=error@entry=0x7ffc5783fa50) at gapplication.c:2049
        __func__ = "g_application_register"

full stacktrace: https://dl.dropboxusercontent.com/u/49862637/Mate-desktop/Bugs/caja-backtrace-GtkApplication-with-sudo
Here caja crashed because a root session org.gnome.SessionManager is missing, imo.

And with dev-GtkApplication2 branch the --browser option is missing.

[rave@f25-gtk3 ~]$ caja --no-desktop --browser
(process:6208): GLib-GIO-CRITICAL **: g_settings_get_value: assertion 'G_IS_SETTINGS (settings)' failed
(process:6208): GLib-CRITICAL **: g_variant_get_type: assertion 'value != NULL' failed
(process:6208): GLib-CRITICAL **: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed
(process:6208): GLib-CRITICAL **: g_variant_get_boolean: assertion 'g_variant_is_of_type (value, G_VARIANT_TYPE_BOOLEAN)' failed
(process:6208): GLib-CRITICAL **: g_variant_unref: assertion 'value != NULL' failed
Could not parse arguments: unknown option --browser

Anyway, best state of work on this issue, thank you.

[lukefromdc]

Just pushed one more commit to dev-GtkApplication2 to restore function of --browser. Just tested it, it will open a window in browser mode even when Caja on the desktop is in spatial mode. So will simply invoking "caja" as the preference "open each folder in its own window" seems to apply only to the initial invocation (known in GtkApplication as the local instance).

Nautilus dumped the Spatial mode before Nemo was forked, so had this option (which the code does not actually do anything with) opened a spatial window I would have had to write code from scratch to ensure that caja --browser actually opened a browser window. It does anyway so I get a break.

[lukefromdc]

I looked at your backtrace and there may be a simple fix: only register Caja when not running in root

[lukefromdc]

raveit65, See if lukefromdc@6a8d0cf stops segfaults when invoking "sudo caja" with your GTK version. If so, Nemo should also use this to stop problems with some GTK versions. This commit limits registering the app with the session manager to invocations running in MATE and not running as root.

[raveit65]

Yeap, --brower and 'sudo caja' work now with gtk+-3.21.4.
I'm not sure about limiting that to mate-session,

if (!running_as_root () || running_in_mate ()){

because i had reports from users who use caja in kde or xfce. Also it seems that caja is an alternative for flashback session.
Well, in the end we should wait if the sudo issue is fixed with next gtk+ release.

[lukefromdc]

I can easily take out the limitation to a mate-session, that is trivial to do.
I was just following the same setup used for desktop management where
to get a desktop in other sessions you have to pass an environmental
variable specifying the session as MATE anyway. If one changes so should
the other.

On 8/16/2016 at 5:38 PM, "raveit65" notifications@github.com wrote:

Yeap, --brower and 'sudo caja' work now with gtk+-3.21.4.
I'm not sure about limiting that to mate-session,

if (!running_as_root () || running_in_mate ()){

because i had reports from users who use caja in kde or xfce. Also
it seems that caja is an alternative for flashback session.
Well, in the end we should wait if the sudo issue is fixed with
next gtk+ release.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
240247695

[lukefromdc]

Having caja try to find a session manager as root that is not running always
puts error messages in the terminal, indicating that trying to connect to an
absent session manager is itself an error.

The sudo issuse should thus keep this fix-unless we want to set up
Caja to run normally in a root MATE session as a whole. That would
require reverting both of these changes and also removing the block
on showing the desktop while running as root. I'll take out the
"running_in_mate" portion of this tonight though so other session managers
can use it the same way.

On 8/16/2016 at 5:38 PM, "raveit65" notifications@github.com wrote:

Yeap, --brower and 'sudo caja' work now with gtk+-3.21.4.
I'm not sure about limiting that to mate-session,

if (!running_as_root () || running_in_mate ()){

because i had reports from users who use caja in kde or xfce. Also
it seems that caja is an alternative for flashback session.
Well, in the end we should wait if the sudo issue is fixed with
next gtk+ release.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
240247695

[lukefromdc]

I pulled out the code to limit registering caja to mate-sesions, left in
the not as root portion. One thing I do not need in my own use of this
code is to get another bad version of GTK and have Caja and Nemo
both segfaulting at the same time as root, because I use root all the
time in packing the results of checkinstall into Debian packages without
the copies of extraneous files (like icon caches and all of /usr/share/mine)
that checkinstall can pick up.

At any rate, this can easily be set up any way we want when GTK 3.21.5
comes out.

On 8/16/2016 at 5:38 PM, "raveit65" notifications@github.com wrote:

Yeap, --brower and 'sudo caja' work now with gtk+-3.21.4.
I'm not sure about limiting that to mate-session,

if (!running_as_root () || running_in_mate ()){

because i had reports from users who use caja in kde or xfce. Also
it seems that caja is an alternative for flashback session.
Well, in the end we should wait if the sudo issue is fixed with
next gtk+ release.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#570 (comment)
240247695

[lukefromdc]

I finally get session saving and reloading to work with lukefromdc@6cb010e
As of now dev-GtkApplication2 should be at feature parity with master, even --help-sm-client works now. Also applied a couple of minor Nautilus bugfixes.

[lukefromdc]

Does anyone have a list of the non-standard use configurations for Caja? I've got dev-GtkApplication3 behaving rather well other than deliberately keeping the case from master where turning off the desktop and setting exit with last window creates a restart loop. I left that alone because I didn't want to create any intentional behavior changes. Otherwise I would have forced hold-in on all autostarted instances.

I've tested spatial and browser windows as user and root, intentional bad URIs, relative paths, various restart conditions, etc but really could use a list of things that need testing, especially those common in scripts. I can do a lot of this testing while we wait for the next GTK 3.21 release.

[lukefromdc]

Commit 9fb1211 is a most of the way fix for the inabily to use --geometry with a second (local) instance of Caja imported from Nautilus 3.4/Nemo with the command line fix for relative paths. Can use --geometry or --browser but not both at once at the moment.

That is because commit uses the "hint" string passed to "open" to send either --browser or a geometry string to the main running instance, but cannot do both at once without more string manipulation than I know how to do right now. If the "hint" string was "600x600browser" or "browser600x600" the browser/spatial switch could easily look for "browser" but the geometry string would have to be separated from the combined string before it could be used. If someone can help me with this string handling I could get the --browser and --geometry options to play nice together.

The only other way to pass options from the local instance's command line to the main instance without screwing up relative paths is to do it the way Nautilus now does. I tested that, it worked but broke passing the command line options to the session manager, so to use it with session saving would require rewrites in cut-n-paste-code/libegg too. I found that out while hooking other options back up one by one and called it at that point. The "hint" method also offers Nemo a fix for their --geometry bug.

BTW, --geometry does not work in spatial windows with master, so it does not here either. Something in the spatial window code either ignores or does not get the string. Not sure how important that is, but we DID recently get an issue from someone who wanted to know how to enable spatial windows.

[lukefromdc]

Finally fixed using --geometry and --browser together, plus rebased and squashed again for today's change in master.
lukefromdc@7990c73
Session saving, autostart, --quit, --check, -n,--geometry, --browser all working fine.

[lukefromdc]

Closed by
9e5ea15
Which adds a --disable-libunique build time option to build with code porting to GtkApplication for distros no longer shipping libunique or to build with libunique by default if this is not passed to ./autogen.sh

[lukefromdc]

Update: Debian Stretch is now in "soft freeze" with full freeze in a month. This means no new packages added or removed-and libunique is still in the repos at
https://packages.debian.org/stretch/libunique-3.0-0
This means an emergency early release of MATE 1.18 should not be needed and in fact would not be used in Stretch, as MATE 1.16 as of now should still be buildable, Caja and other programs using libunique and all. This permits Debian to use older, well-proven code in what amounts to an LTS instead of going with a brand-new release.

My guess now is that libunique will be removed from Debian Unstable sometime after the release of Stretch.