New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GTK 3.21.3: no desktop redraws or bg changes until restart #575

Closed
lukefromdc opened this Issue Jun 20, 2016 · 64 comments

Comments

Projects
None yet
4 participants
@lukefromdc
Copy link
Member

lukefromdc commented Jun 20, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jun 21, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jun 22, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jun 22, 2016

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

This comment has been minimized.

Copy link
Member

willysr commented Jun 22, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jun 22, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jun 22, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jun 24, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jun 28, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jun 28, 2016

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:
#575 (comment)
229027252

@raveit65

This comment has been minimized.

Copy link
Member

raveit65 commented Jun 28, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jun 28, 2016

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

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jun 28, 2016

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:
#575 (comment)
229175664

@raveit65

This comment has been minimized.

Copy link
Member

raveit65 commented Jun 29, 2016

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

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jun 29, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jun 30, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 4, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 4, 2016

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

@raveit65

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 4, 2016

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 comment has been minimized.

Copy link
Member

lukefromdc commented Jul 4, 2016

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:
#575 (comment)
230354361

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 4, 2016

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:
#575 (comment)
230354944

@raveit65

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 4, 2016

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

This comment has been minimized.

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 4, 2016

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:
#575 (comment)
230361091

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 7, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 8, 2016

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

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 22, 2016

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.
GNOME/nautilus@f0f36c8
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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 23, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 23, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 23, 2016

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:
#575 (comment)
234729242

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 24, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 24, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 24, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 25, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 25, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 29, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 29, 2016

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

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 29, 2016

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

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 29, 2016

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:
#575 (comment)
236150289

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 29, 2016

I'll have a look at the overall changes and see if use of selectors is possible
within the same files.

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:
#575 (comment)
236150289

@raveit65

This comment has been minimized.

Copy link
Member

raveit65 commented Jul 31, 2016

I noticed 2 little regression with testing latest changes from Pr and you branch for mate-settings-daemon.
Background-fade does not work any more if compositor is used.
Also it isn't a good idea to change something in settings, eg. disable desktop icons.
Than the desktop start is very slow after a logout until you restart the system, than desktop start is normal again.
And i see always the progress cursor a while during session start.
Looks like that something with the setting-daemon isn't optimal.

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Jul 31, 2016

Also I will obviously have to revert the change from GTK 3.21 to GTK3
selectors in m-s-d to match the Caja branch

On 7/31/2016 at 11:25 AM, "raveit65" notifications@github.com wrote:

I noticed 2 little regression with testing latest changes from Pr
and you branch for mate-settings-daemon.
Background-fade does not work any more if compositor is used.
Also it isn't a good idea to change something in settings, eg.
disable desktop icons.
Than the desktop start is very slow after a logout until you
restart the saystem, than desktop start is normal again.
And i see always the progress cursor a while during session start.
Looks like that something with the setting-daemon isn't optimal.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#575 (comment)
236436044

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Aug 1, 2016

Two matched PRs for this:
mate-desktop/mate-settings-daemon#157 for m-s-d
#602 for caja
Both affect only GTK 3.21 and later builds.

The fade regression appears to be a problem in mate-desktop and appears also with m-s-d master and no icons on the desktop. Suspect function is mate_bg_set_surface_as_root_with_crossfade which is found in mate-bg.c

The session hangs after configuration change I was entirely unable to duplicate when turning icons on the desktop on and off or anything else.

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Aug 2, 2016

More has been added to https://bugzilla.gnome.org/show_bug.cgi?id=768415 including these lines:

"My suspicion is that Nautilus 3.4 is expecting to handle expose events on the desktop window, whereas that is not necessary. Alternatively, Nautilus is trying to draw on a native window with double buffering."

The second case I just tested with this code in caja-icon-container.c:
in function "realize" in caja-icon.c:

 /* Ensure that the desktop window is native so the background
       set on it is drawn by X. */
    if (container->details->is_desktop)
    {
#if GTK_CHECK_VERSION (3, 0, 0)
    gtk_widget_set_double_buffered (GTK_WIDGET (container), FALSE);
#else
        gdk_x11_drawable_get_xid (gtk_layout_get_bin_window (GTK_LAYOUT (widget)));
#endif

This removed the code making the desktop window native and disables double buffering (like in Marco). The results were quite ugly and the same with or without the code to turn off double buffering: Redraw bug plus windows open when Caja opens added to the background.

example_screenshot

All those "open windows" you see BEHIND the icons are not windows at all, they are just images of windows added to the rendered background

If the desktop is transparent, then removing the native window code is what makes it work. This workes for Nautilus, Nemo, and for the transparent branch of Caja but won't work with the background drawn by Caja. OK, how would we go about not handling expose events on the desktop window? Keep in mind, the offending code in GTK itself is in a "case GDK_EXPOSE:" switch.

@raveit65

This comment has been minimized.

Copy link
Member

raveit65 commented Aug 2, 2016

I'm a good theme artist and a good rpm packager, i understand nothing about you're speaking and i'm not able to ask for more help in gnome report for this reason.

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Aug 2, 2016

I finally managed to get on their bugzilla, had to make a new account
from scratch, from another email address, on a special browser run
with referrer headers enabled. I hope I am not blocked on next login
there. I posted some details along with that ugly screenshot, and
while still logged in also a bug report on a recent run of build failure
going back a week now.

On 8/2/2016 at 3:21 PM, "raveit65" notifications@github.com wrote:

I'm a good theme artist and a good rpm packager, i understand
nothing about you're speaking and i'm not able to ask for more
help in gnome report for this reason.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#575 (comment)
237014276

@raveit65

This comment has been minimized.

Copy link
Member

raveit65 commented Aug 3, 2016

Thank you,
Maybe you can use gtk_render_background for non compositor usage?
https://developer.gnome.org/gtk3/unstable/GtkStyleContext.html#gtk-render-background

Typical background rendering, showing the effect of background-image, border-width and border-radius:

This should give us the property background-image

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Aug 3, 2016

I would have to figure out where to fetch the cairo_t to use gtk_render_background, splitting this out for the noncompositing case might be smart because it both allows us to get ahead of the situation now, and because in the compositing case it is lighter code to show what is already being rendered behind the desktop. May take me a while to play with this , and I hope it doesn't just bring back the nasty redraw issues or crash Caja with "bad pixmap" errors like I got until I stripped out every use of the old background rendering code from the GTK 3.21 builds. Certainly worth a try.

@raveit65

This comment has been minimized.

Copy link
Member

raveit65 commented Aug 4, 2016

PRs are merged.

@raveit65 raveit65 closed this Aug 4, 2016

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Sep 1, 2016

Debian Unstable just brought in GTk 3.21.5-but is still shipping caja 1.14.2. I haven't tested their packages but with my 1.14 Caja this will mean no desktop redraw plus segfaults on opening windows caused by the old places sidebar issue. They need a point release-or to update to 1.15.4 right quick

#627

EDIT: I have also submitted a bug report to Debian over this

@geki-yaba

This comment has been minimized.

Copy link

geki-yaba commented Dec 7, 2016

I have a similar issue with current MATE 1.16.x packages and Gtk 3.22.4.
The desktop is not redrawn when it should. May I open a new issue? And for what project?

Demonstrated in the video:
http://geki.selfhost.eu/hacks/mate-desktop.mkv

@lukefromdc

This comment has been minimized.

Copy link
Member

lukefromdc commented Dec 7, 2016

Did you (or your distro) update to GTK 3.22 after your last update of Caja? The changes in Caja for GTK 3.22 are only used if Caja is built against GTK 3.22 however. If you have a build of Caja 1.16 that was built against GTK 3.20 or earlier, the changes were not used in the build and this is exactly the behavior you'd get.

If you can build from source, try building caja locally, it should work fine. I have GTK 3.22.4 here and no problems with 1.16 or 1.17.

@geki-yaba

This comment has been minimized.

Copy link

geki-yaba commented Dec 8, 2016

O ha, I thought I had recompiled MATE after Gtk upgrade. Seems that not. Am on Gentoo Linux, had to recompile world(all installed packages) after partly toolchain update to hopefully solve another issue.

Now it works. What a faux pas. Sorry for the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment