GTK 3.21.3: no desktop redraws or bg changes until restart

[lukefromdc]

Beginning with the various GdkDrawingContext changes to GTK during the 3.21.2 cycle, the desktop background in Caja has become "persistant" with a failure to redraw and "erase" when any icon is moved. In addition, all icon and text shadows are rendered at 100% opacity and the background cannot be changed. Restarting caja or adding/removing a secondary monitor will forcibly redraw the desktop, erase no longer valid images, and apply background changes. Nemo also has this problem, nautilus with the new split-out "nautilus-desktop" binary does not and in fact running an instance of nautilus-desktop in a MATE session with normal desktop icons turned off is a workaround for this.

In searching for this, I have gotten as far as the function "draw_canvas_background" in caja-icon-container.c . If this function and the reference to it elsewhere in the same file are removed, no background can be rendered (as expected) but icons can now be moved around and shadows render normally.

The desktop background failed redraw issue exists in Master(where I first saw it), in dev-style-properties, and even in my dev-deprecations-3.21 branch where the newly deprecated gdk_cairo_create() was replaced with cairo_create()

The buggy GTK changes have now made it out the door in GTK 3.21.3, implying they are now far more likely to persist all the way to final GTK 3.22. This broke a lot of things, like causing Firefox to render solid black until each widget is focussed, but it now looks like GTK devs expect all of us app developers to find and fix the major fallout from these gdk changes ourselves.

[lukefromdc]

Just found the exact GTK commit causing this problem: https://git.gnome.org/browse/gtk+/commit/?id=2c7b21718f18ab743cd79784ae28cad582f58503 "Simplify the widget rendering entry point" lots of internal changes in gtkwidget internal cairo interaction

[lukefromdc]

More experiments with Caja and GTK 3.21/3 tonight.

killing mate-settings-daemon or (in another DE) starting mate-settings-daemon, cinnamon-settings-daemon, or gnome-settings-daemon will force the background to redraw and "clean" the desktop. At this point icons and text render normally. Clicking on the desktop will darken shadows until after about 4 clicks they are opaque. This or any other interaction redraws all icons and text without erasing. Behavior is as though on each redraw the entire desktop canvas was composited with the last copy of itself rather than the background. The failed redraw also blocks background changes, though that will work with icons on the desktop turned off.

[raveit65]

Do we see gtk4 here? I'm still wondering that gtk+-3.21.2 and 3.21.3 isn't packed in fedora rawhide. Latest version is 3.21.1 here, maybe they prepare the gtk4 branch here.

[willysr]

Slackware 14.2 will ship with GTK+3-3.18 so it's a long way before next Slackware and by that time, it should be solved :)

[raveit65]

Slackware 14.2 will ship with GTK+3-3.18 so it's a long way before next Slackware and by that time, it should be solved :)

I'm really tired about your comments. Why you give a fuck about other desktops. If Mate isn't usable anymore in next fedora releases you can develop Mate alone for you deprecated Slackware.

[lukefromdc]

I WISH this was for GTK 4! GTK 3.21.3 tarballs are available from gtk.org and I've been working against GIT master, except for having to alternate between "test" and "usuable" versions for the past two week,.

There is discussion on Phoronix that GTK 3.24 might be the final GTK3 version and then there will be several "unstable" GTK4 versions that non-GNOME developers are asked not to target, followed by a "stable" GTK 4 at about GTK 4.6. If GTK 3.22 and GTK 3.24 are so different from GTK 3.20 and earlier as to make a lot of things incompatable, distros might want to think about stopping GTK3 updates at 3.20 or even 3.18, then targetting GTK 4.6 when it comes out for any further work. Trouble with that is that "legacy" updates and bugfixes in the future would only go to the "GTK 3.50" GTK 3.24 down the road.

From the commit itself:" Candidate for deletion in the next major API bump." I DO hope that means GTK 4!

[lukefromdc]

I just uploaded the file for a "workaround" special build of nautilus-desktop renamed caja-desktop to Github: https://github.com/lukefromdc/caja-desktop it's a hack and has to be built inside Nautilus, which must also be installed at runtime. Modifications are calling mate-appearance background on right-clicking the desktop and selecting "background" so you can change backgrounds with it, and renaming it. Crude but lets me run GTK 3.21 from master while waitng for the GTK devs to fix this, someone else to find the issue, or to find out myself why Nautilus doesn't have this nasty redraw bug but Nemo and Caja both do. The fact that Nemo does shows that the transparency instead of copy the background changes both have from Nautilus 2.0 probably wasn't what fixed this, but for the life of me I cannot find this bug after over a week of experiments so I need this workaround!

[raveit65]

Would be interesting to know which gtk+ commit causes the desktop issue since the 'double buffer' commit is fixed for firefox. You can use 'git bisect' on gtk+ to find out the culprit commit. And sorry, i can't help as fedora rawhide use 3.21.1 and they do not update.

[lukefromdc]

I already did a manual bisect (applied commits one at a time for builds) and found the exact commit in question:

https://git.gnome.org/browse/gtk+/commit/?id=2c7b21718f18ab743cd79784ae28cad582f58503 "Simplify the widget rendering entry point"

On 6/28/2016 at 7:52 AM, "raveit65" notifications@github.com wrote:

Would be interesting to know which gtk+ commit causes the desktop issue since the 'double buffer' commit is fixed for firefox. You can use 'git bisect' on gtk+ to find out the culprit commit. And sorry, i can't help as fedora rawhide use 3.21.1 and they do not update.

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 229027252

[raveit65]

OK, this is from 2016-05-20. Looking in nautilus git shows me there are not much commits and non of them seems related. So from which nautilus version you borrowed the code?

[raveit65]

err...... i meant after this date.

[lukefromdc]

I goit my test functions from Nautilus master last night-and found that file to have gotten no new commits in years.

On 6/28/2016 at 4:38 PM, "raveit65" notifications@github.com wrote:

err...... i meant after this date.

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 229175664

[raveit65]

So, can you point me to the file at gnome git?

[lukefromdc]

I've been doing so many different things with the various problems here I've lost track of what I was doing Monday night. I've been playing with these files mostly:

caja-desktop-window.c fm-desktop-icon-view.c caja-icon-container.c

Nautilus equivalents are

nautilus-desktop-window.c nautilus-desktop-canvas-view.c nautilus-canvas-container.c

I DID try various versions of Nautilus hoping I could narrow down to and finally bisect to the commit that made Nautlus work. I was able to build Nautilus all the way back to 3.8 but no older before getting build failures against GTK 3.21. That old 3.8 version had to have .background and window set transparent globally to render the desktop but then worked fine with no redrawing issues. Can't bisect because nothing older can be built. The change had to be somewhere between 3.4 (when Nemo forked off) and 3.8(which works) because Nemo also has the redrawing issue. Nemo like Nautilus renders a transparent desktop window without copying the background and does not work on the desktop without compositing. Therefore that alone cannot be the difference.

I also tried manually applying those old Nautlus commits for a transparent rather than copied desktop background to Caja. Got all kinds of problems but could render the desktop long enough to move an icon and still get the redrawing problem, so it has to be something else.

[lukefromdc]

There is a possible clue to this from the last GTK dev cycle: remember when gtk changes caused the view backgrounds to become always transparent? Given that that works even without compositing it implies that the FMIconContainer widget now draws on the window of the widget beneath it , that being the scrolledwindow, which is still background themable in non-desktop windows. What we are getting appears to be the foreground content becoming treated as the background when the foreground is redrawn, that foreground being the contents of the FMIconContainer .view widget. Possibly with GTK 3.21.3, the GDK changes are causing this to draw into the same buffer as the background?

Alternately, the fact that the background also cannot be changed might mean the wrong widget or buffer is being updated when the background is being told to redraw. The right redraw occurs when mate-settings-daemon is restarted, and I've verified that the daemon starting, not the daemon stopping, is what redraws the desktop and "cleans" the non-redrawn garbage off it.

Thus, whatever signal is being sent when mate-settings-daemon is started needs to be sent every time the foreground or the background is updated, or whatever background update mode it causes needs to be used not only for all background redraws, but also all foreground redraws as well.

What exactly happens in Caja when m-s-d is first started if Caja was running first? If I can find that I can probably fix this issue.

[lukefromdc]

We may not get much help from GNOME on this. I sent an email to the author of the commit that broke the desktop, got a reply asking me to send a bug report. Only thing is, the GNOME bugzilla cannot be used with my locked down security browsers, calling logins untrusted and that sort of thing. I won't go online with trackers etc enabled to diagnose that, so I will not be able to file a bug report with GNOME against anything. I send an email back about the blocked logins but do not expect to hear any further about it.

Since Nemo is also broken, I expect that distros won't ship GTK 3.22 at all unless and until this is fixed, as it only works in GNOME if you want icons on the desktop. Nemo is bottomlined by LinuxMint, which probably will be on GTK 3.18 for the next four years. I heard Fedora Rawhide has not shipped anything past GTK 3.21.1, so I wonder if they are blocking 3.21.3 for this very reason or for another, possibly similar reason.

Since 3.24 is scheduled to be the last version of GTK3. distros really do have a choice here: they can stop at GTK 3.20, with no further updates until GTK 4 goes stable in about 2 1/2 years.

[raveit65]

NP, i can do that for you. Can you send a text to my mail address? chat-to-me@raveit.de

[raveit65]

As i'm fedora packager i have to live with gtk3 updates from overloards. I switched Mate for fedora rawhide (fedora 25) to gtk3, so i'm really interested to fix that, but i can't reproduce or work on it as rawhide isn't updated to culprit gtk+ versions from fedora side.

[lukefromdc]

This is a desktop computer with no text message function, can this address take a standard email?

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

NP, i can do that for you. Can you send a text to my mail address? chat-to-me@raveit.de

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 230354361

[lukefromdc]

GTK3 buiids easily from source. If you have enough development packages installed to build MATE itself little more is needed to build GTK3 from master. That's where I am getting it.

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

As i'm fedora packager i have to live with gtk3 updates from overloards. I switched Mate for fedora rawhide (fedora 25) to gtk3, so i'm really interested to fix that, but i can't reproduce or work on it as rawhide isn't updated to culprit gtk+ versions from fedora side.

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 230354944

[raveit65]

This is a desktop computer with no text message function, can this address take a standard email?

sure, this is my normal address for linux.

[raveit65]

https://bugzilla.gnome.org/show_bug.cgi?id=768415

[lukefromdc]

Thanks, let's see if this helps. For the moment I am trying to port the desktop split in Nautilus to older Nautlius 3.16 so I can build the workaround "caja-desktop" fork of nautilus-desktop with a caja-style renaming label instead of that damned popover.

On 7/4/2016 at 6:45 PM, "raveit65" notifications@github.com wrote:

https://bugzilla.gnome.org/show_bug.cgi?id=768415

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 230361091

[lukefromdc]

I just found the exact part of https://git.gnome.org/browse/gtk+/commit/?id=2c7b21718f18ab743cd79784ae28cad582f58503 that is causing our problems here, by simply reverting portions of the commit. Removing the code below causes all the trouble. (could NOT use the "code markers" or the patch format w/o corrupting the display of it here!

In GTK's gtk/gtkmain.c under "case GDK_EXPOSE:"

      {
          gboolean is_double_buffered;

          G_GNUC_BEGIN_IGNORE_DEPRECATIONS;
          is_double_buffered = gtk_widget_get_double_buffered (event_widget);
          G_GNUC_END_IGNORE_DEPRECATIONS;

          if (is_double_buffered)
            {
              /* We handle exposes only on native windows, relying on the
               * draw() handler to propagate down to non-native windows.
               * This is ok now that child windows are always considered
               * (semi)transparent.
               */
              if (gdk_window_has_native (event->expose.window))
                {
                  gdk_window_begin_paint_region (event->any.window, event->expose.region);
                  gtk_widget_send_expose (event_widget, event);
                  gdk_window_end_paint (event->any.window);
                }
            }
          else
            {
              gtk_widget_send_expose (event_widget, event);
            }
        }

The added

gtk_widget_render (event_widget, event->any.window, event->expose.region);

can be added back (giving a double render) without breaking icon dragging and background changing, though double rendering then makes shadows twice as dark as they should be. Also, a faint background dragging with an icon artifact seen in GTK 3.21.3 then returns, identifying the new code as the source of that artifact.

I will be applying the inverse of GTK's patch to every new build of GTK3.21 until this is fixed right. To fix this is Caja we need some way to execute that code ourselves and keep it away from GTK it seems. If they remove gtk_widget_send_expose entirely of course this will break.

[raveit65]

Is GDK_EXPOSE not gtk2 only. I recall that it is replace with .....draw in most code. @monsta ???

[lukefromdc]

gdk_send_expose was used inside GTK3 until 3.21.3 and not using it there anymore may be the cause of the caja desktop problems in GTK 3.21.3.

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

Is GDK_EXPOSE not gtk2 only. I recall that it is replace with .....draw in most code. @monsta ???

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 231471809

[lukefromdc]

I did some further digging into the GTK patched today and here's what I found: the critical part without which the desktop in Caja won't redraw is

   if (gdk_window_has_native (event->expose.window))
                {
                  gdk_window_begin_paint_region (event->any.window, event->expose.region);
                  gtk_widget_send_expose (event_widget, event);
                  gdk_window_end_paint (event->any.window);
                }

Replacing the "paint" lines with the gtk_widget_render line from the new version causes the desktop not to redraw, while removing send_expose causes Caja windows to render black and the desktop not to render at all while Caja continues to run in the background. Thus the "paint" lines are the ones that count for redrawing the desktop, my suspicion now is that something in the icon rendering code needs to use it directly.

[lukefromdc]

I just found the Ubuntu GNOME PPA https://launchpad.net/~ricotz/+archive/ubuntu/testing is sitting on version 3.21.2 built over a month ago on 5-27-2016. Looks like almost everyone has blocked version 3.21.3 at this time, possibly waiting to see what 3.21.4 will do. Possibly that's because the Firefox fix didn't make it to the 3.21.3 tarball? It will be interesting to see what happens with the 3.21.4 tarball if that only fixes Firefox and not the non-Nautilus file managers. Edit 7-14: that PPA is still offering the same, now month and a half old build of 3.21.2

[lukefromdc]

I traced two warnings my hybrid GTK 3.21 builds to gdk_window_begin_paint_internal and gdk_window_end_paint_internal in gdkwindow.c, both of which simply exit and issue a warning if something else is already drawing the window. For my purposes I commented out the warnings so they would not spam my terminais. but that means that what makes the gdk_window_begin_paint and gdk_window_end_paint lines in gtkmain.c so important could be nothing more than forcing a function with a problem rendering the desktop to exit.

[lukefromdc]

GTK 3.21.4 has just been released including the Firefox fix. No fix for the Caja/Nemo issue in it other than my locally applied patch though.

Let's see if it was only the Firefox issue that blocked 3.21.3 from Fedora Rawhide and the Ubuntu GNOME PPA. I have a patched version of 3.21.4 that works with caja and nemo published within this archive page: https://archive.org/details/DebianPackagesForMate-desktopWityGtk3AndCustomPanelTheme

[raveit65]

Now i see that with 3.21.4 in fedora rawhide. This is a serious blocker for me, as i switched Mate in fedora rawhide to gtk3.

[raveit65]

I just added this report to tracker report with a MUST.

[lukefromdc]

I have been forced to patch GTK in my machines to partially revert the offending commit. if GNOME refuses to fix it and no fix is found elsewhere distros will either have to do the same, ship only GNOME and KDE, or block GTK 3.22.

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

Now i see that with 3.21.4 in fedora rawhide. This is a serious blocker for me, as i switched Mate in fedora rawhide to gtk3.

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 233921933

[lukefromdc]

Re Nautilus 3.7.9x builds and getting a gray desktop: that is because the desktop is getting the default background color with GTK 3.21 and does not have a style class nor code to avoid it. Setting the background for all windows transparent in a test theme will fix this, someone reported using Adwaita also does.,

I will try https://git.gnome.org/browse/nautilus/patch/?id=6d6bf1e7c6049b4bd300ae1d90833a8b5fcf30c4 on Nemo, it's reported to work. If it works for me I will see if it has any relevence to caja but i've seen that xid/native window code already used somwhere in Caja, not sure if it's the same place though. If we already have something similar or it does not work, I will port over the "entire desktop is transparent, settings daemon sets the bg" change and add this to it. That is a compositing-only fix if it comes to that and would require Marco to always be a compositor when built against GTK 3.22 but would make MATE possible to use with GTK 3.22/

[lukefromdc]

Looking further, I tried removing the xid/native window code in Caja nearly a month ago, and in Caja's case it made matters far worse, causing windows open when caja opens to get added to the background too. if it works as the before/after commit in Nautilus I will then try it in Nemo, and if that works try it with Nemo's desktop transparency patch in Caja

[lukefromdc]

https://github.com/GNOME/nautilus/commit/6d6bf1e7c6049b4bd300ae1d90833a8b5fcf30c4 canvas-container: don't force native window for the desktop canvas

did in fact make the difference in Nautilus, but only when used with a second, earlier commit to permit a transparent window. Otherwise it turned black if set transparent and could not show the desktop background at all.

https://github.com/GNOME/nautilus/commit/f0f36c876e4810b190a82e3a953d9263c106447f Use an RGBA window for the desktop -JUST the changes to nautilus-desktop-window.c if only the desktop is in question, as it permits the window to take an alpha value and become transparent, the nautilus-desktop-canvas-view file worked without changes.

ALL themes then put their default window background on the Nautilus desktop, but if that background was transparent a functioning desktop resulted. Easily hardcoded transparent but this was just test code.

I tried exactly this in Caja a month ago but got rather different results. A rough port of the full Nautilus desktop tranparency code ran poorly but ran long enough to show I still had the problem. Adding the don't force native window commit not only did not fix the issue, it made it worse by causing the background to pick up images of windows open when caja was opened too. Was a bad port and obviously something was missing though because it is now clear this can work.

When I just tried this in Nemo I got a white but otherwise functioning desktop, will have to find that, code it transparent, see if it works, and if it does commit it to my nemo branch. A sucessful port to Caja again would fix the desktop but depend on use of a compositing window manager to show the background. SpaceFM-gtk3 is able to render a background cleanly with GTK 3.21 but the build I have segfaults on any attempt to interact with an icon.

[lukefromdc]

Just submitted this PR for Nemo: https://github.com/linuxmint/nemo/pull/1232 Quite simple: apply https://github.com/GNOME/nautilus/commit/f0f36c876e4810b190a82e3a953d9263c106447f and then force the desktop-icon-view (scrolledwindow) transparent with my old cssprovider method from the caja 1.12 "flashfix" days.

[lukefromdc]

The Nautilus/Nemo fixes did not work in Caja, just as they did not when I tried the same thing a month ago. Got instabilty, sometimes "bad pixmap" crashes,and still had the redraw issue even on a transparent desktop. https://github.com/GNOME/nautilus/commit/f0f36c876e4810b190a82e3a953d9263c106447f seemed to be the first commit of the series with no obvious predependencies, yet was the cause of all the stability problems and bad pixmap errors I got. I will try Nemo's commits for this tomorrow, I recall more stability and less trouble when I tried them a long time ago.

[lukefromdc]

I finally managed to build a version of Caja that works with GTK 3.21.3 or later, and it does complete distcheck as well:

https://github.com/lukefromdc/caja/tree/GTK-3.21-desktopfix

This branch is GTK 3 only. Worse, the fixes from Nemo and Nautilus make the desktop dependent on compositing to show the background and not solid black. None the less, this does work and permits Caja to be used with GTK 3.21.3 or later so long as either Marco with compositing turned on or compiz is used. Other compositing WMs should also work.

The other possible fix would be to find a way to get the icon container to force the background to update from a fresh copy of the background image and not the previous combined image on every redraw but I cannot code that. EDIT: The advantage would be saving the non-composited option for Marco, which would otherwise have to be disabled.

It is possible to use "doubled" files with build time selectors to re-enable GTK2 if we decide to keep the GTK2 option for 1.16. The top half of the files with big changes would be all GTK3, the bottom half all GTK2 and the selectors in between. Some would just need normal selectors around a couple deleted lines.

[raveit65]

I just tested it and it does what it promised, thank you. But i can't switch the wallpaper or background color if compositor is enabled. It looks like that always the default wallpaper is displayed which is loaded by lightdm here. Anyway, good job. Do you think it is possible to make all changes gtk3 only when it is finished? I'm in doubt that @monsta agree with switching to gtk3 only code for 1.16 if we can avoid that. With make files i can help. Maybe separating the files in 2 sections, one for gtk2 and one for gtk3 ? Edit: you said this already :)

[lukefromdc]

I will be very busy and out of town tomorrow but could later do a 'split file" job for exactly this purpose, simplty appending the GTK2 only code beneath the modified files with the selectors.

Using my "combined" build with both the GtkApplication and the Gtk 3.21 work I got a surprise on first boot, with Caja starting ahead of the compositor and getting a black background. Marco is set compositing and a script switches to Compiz, I think with the .desktop file startup it came up during the switch between them.

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

I just tested it and it does what it promised, thank you. But i can't switch the wallpaper or background color if compositor is enabled. It looks like that always the default wallpaper is displayed which is loaded by lightdm here. Anyway, good job. Do you think it is possible to make all changes gtk3 only when it is finished? I'm in doubt that @monsta agree with switching to gtk3 only code for 1.16 if we can avoid that. With make files i can help. Maybe separating the files in 2 sections, one for gtk2 and one for gtk3 ?

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 234729242

[lukefromdc]

Caja starting with a black or default lightdm background at the beginning of the session turned out to be an issue in mate-settings-daemon, which still expected Caja to manage the background. https://github.com/lukefromdc/mate-settings-daemon/tree/gtk-3.21-cajafix fixes that and you can now set backgrounds normally in Caja and your selected background comes up right away with the session. This caja branch and that m-s-d branch must be used together.

Edit: m-s-d branch changes only GTK 3.21 or later builds for now. Assuming Caja is changed for all GTK3 builds or goes GTK3 only with this code used in all cases that will have to change. Three-part files for GTK 3.22, GTk 3.14-3.20. and GTK2 are actually possible and would avoid imposing this composite-only crap on distros using older GTK version until they too use 3.22 or later. Lots of extra work but might be worth it. The MSD branch is three-way now.

[raveit65]

You did it, awesome. All is working now. I will use your patches for caja and m-s-d and update fedora rawhide. No need that people have to wait only why we don't fell an decision to make caja gtk3-only or not. I will open an RFE to discuss this with the other guys. I don't think that it make really sense to do a PR or further work on GtkApplication port for you, without to know in which direction it goes.

Thanks a lot

[raveit65]

Looks like i can use the patched from https://github.com/lukefromdc/caja/tree/GTK-3.21-desktopfix only use for gtk+-3.21.x branches? I ask because i build Mate gtk3 with 1.15 for all fedora/rhel7 vesions with my gtk3 repo. https://copr.fedorainfracloud.org/coprs/raveit65/Mate-GTK3/

[lukefromdc]

New m-s-d branch same as my last but this time building same for all GTK3 versions since Caja branch also builds transparent desktop for all GTK3 versions. Use them together https://github.com/lukefromdc/mate-settings-daemon/tree/gtk3_for_gtk3.21compatable-caja.

[lukefromdc]

The GTK 3.21 issue is such a bad mess (and so is the GtkApplication issue) that we might actually be better off with two tarballs for Caja if we want to keep GTK2 compatability. Both build a binary named "caja" but one tarball gets named caja-gtk3. Alternately, top and bottom sections of .c files where that will work, two files where it won't work and makefile + include work to deal with that mess.

if we want to keep GTK 2 for Caja we need a solution to the libunique mess that works for GTK2, or to take over Libunique maintainance ourselves and dump the Nautilus-based changes to Caja for GtkApplication

[lukefromdc]

It's actually possible for this version of Caja (and Nemo and Nautilus as well) to set a background in the noncompositing case in the GTK theme or in the users ~/.config/gtk-3.0/gtkcss file but it must be a solid color or a gradient-and will be applied even when compositing is used unless the code is modified to apply a style class when and only when the visual is an RGB and not an RGBA. Usable widgets are the scrolledwindow or any of the three boxes.

I played with this over a month ago but did not pursue it because no image would work. Is it worth setting a "fallback" background gradient (perhaps the default MATE bg gradient) for the noncompositing case? If we keep the option of running Marco without compositing we need something better than that black default, and we really need to keep it off the desktop when compositing is used, a relatively simple job.

[lukefromdc]

Branch with blue fallback BG when started w/o compositor created: https://github.com/lukefromdc/caja/tree/GTK3.21-desktopfix%2Bfallback Not great but a hell of a lot better than being stuck with black like Nemo and Nautilus. Composting needed to use image bg or set a bg from mate-control-center. In fact, I should remove the "change background" entry from the desktop right click menu when this option is being used-or better yet, add a notation to it that compositing is required for full background functionality. Probably we would want to use the default MATE gradient bg for this, it should work, it's just images that do not.

[raveit65]

Last changes are looking good, so it is possible to use the background-image property?

/*color of desktop when compositor is not available*/
.caja-fallback-desktop-background {
    background-image: ...................;
}

At least i'm bit disappointed about feedbacks or non feedback from some guys in RFE. Looks like nobody doesn't really care if they are not affected in their distros. And i'm really tired about saying NO but don't do anything (coding, testing your work,.....) from some guys. As i'm the first one who have to handle the desktop breakage in next fedora release (f25) in october / november, can we make the changes with GTK_CHECKS for 3.21.0? In result it is possible for me to use them as patches? Also a PR should be fine than as it affect only 3.21, and maybe we find another solution to fix the desktop with non-compositor later. But i don't think that will ever work as for a RGBA window the compositor is needed. For fedora 25 i will look for a way to disable non-compositor usage. This is better as switching back to gtk2 for f25.

[lukefromdc]

I tried the background-image property, it was entirely ignored by these widgets. This was something I tried nearly a month ago, hoping to bypass this whole mess but it seems not all GTK widgets have the internal code to apply an image.

On 7/29/2016 at 6:43 AM, "raveit65" notifications@github.com wrote:

Last changes are looking good, so it is possible to use the background-image property?

/*color of desktop when compositor is not available*/
.caja-fallback-desktop-background {
  background-image: ...................;
}

At least i'm bit disappointed about feedbacks or non feedback from some guys in RFE. Looks like nobody doesn't really care if they are not affected in their distros. And i'm really tired about saying NO but don't do anything (coding, testing your work,.....) from some guys. As i'm the first one who have to handle the desktop breakage in
next fedora release (f25) in october / november, can we make the changes with GTK_CHECKS for 3.21.0? In result it is possible for me to use them as patches? Also a PR should be fine than as it affect only 3.21, and maybe we find another solution to fix the desktop with non-compositor later. But i don't think that will ever work as for a RGBA window the compositor is needed. For fedora 25 i will look for a way to disable non-compositor usage. This is better as switching back to gtk2 for f25.

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/caja/issues/575#issuecomment- 236150289