Do

Should detect when Composite has been enabled/disabled, even when gnome-do is running

Bug #321742 reported by manzur
124
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Do
Fix Released
Medium
Unassigned

Bug Description

Do only checks for the presence of Compositing when the Preferences are shown. This means that if a composite manager is disabled or crashes after Do has started, the UIs are surrounded by their maximum-size black windows. This is ugly for normal UIs, and quite distruptive for Docky.

There's probably a GTK signal we can hook into to switch back to classic if and when the Composite manager goes away.

Revision history for this message
manzur (sl-solaris) wrote :
description: updated
Changed in do:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Γουργιώτης Γιώργος (aka Gourgi) (gourgi) wrote : Re: Should detect when Composite has been disabled.

this happens with the other themes too.
also when this happens , if i click Do's preferences -> Appearance
i can't choose another theme. theme-chooser is locked.

i agree, the theme should switch automatically to Classic
with a notification message why this happened (maybe) ?

Alex Launi (alexlauni)
Changed in do:
milestone: none → 0.8.1
Revision history for this message
Chris Halse Rogers (raof) wrote :

The duplicate bug 324332 is the same problem, but in the other direction (composite turning on). I don't think it's unreasonable to hook in and turn on the fancy effects when Composite becomes available, either.

Revision history for this message
Chris Halse Rogers (raof) wrote :

Indeed, we should be able to just hook up to Gdk.Screen.CompositeChanged

Revision history for this message
Bryan Goldstein (bsg-csh) wrote : Re: Should detect when Composite has been enabled/disabled.

I have a temporary fix for this that I just started using. It isn't the best practice and couldn't be put into a release, but for people who only use gnome-do with compiz it should work fine.

Add this to the top of your /usr/bin/gnome-do file:

pgrep -u "`id -un`" '^compiz$'
while [ $? = 1 ]; do
 sleep 2
 pgrep -u "`id -un`" '^compiz$'
done

It makes gnome-do wait for compiz to start before running.

Grab the attachment if you just want to download the whole script.

Revision history for this message
manzur (sl-solaris) wrote :

but gnome-do should be able to enable another theme while compositing is not working, so it will stay running, and we could use it, and when any compositing is enable it should remember its last theme and enable it again, for example: if we have dock theme enabled and for any reason compiz crashes so gnome do should be able to apply itself classic interface theme, and when we enable compiz, metacity composite manager or cairo composite gnome do should remember the last theme it had before composite crashed so it should apply docky theme again, this is the perfect way.

Revision history for this message
Stuart (sjbertram) wrote :

Apparently a bug I reported (338154) is a duplicate of this bug, but the comment by Γουργιώτης Γιώργος doesn't hold true for me (I can edit the theme when it shows Default, even though I had previously selected something else and the list's default is what I had selected). I use Compiz Fusion on Fedora 10 (the custom build by Leigh) and on OpenSuse 11.1 (Cyberorg's build) with the fusion-icon in my start-up apps.

I'll try Bryan Goldstein's script and see if that helps. I'd already tried a simple "gnome-do && killall gnome-do && sleep 2 && gnome-do" script because "killall gnome-do && gnome-do" manually run from the run dialog got me my theme back, but that didn't generally seem to work (except this morning, so possibly a race condition).

Revision history for this message
Jonathan Austin (mailforwho) wrote :

I use this script to toggle metacity's compositor (it affects video playback on this computer). It also deals with Do. I keep a launcher for it on my panel and it is very useful.

#/bin/bash
killall gnome-do
 if [ $(cat ~/.compositor) = true ]; then
               echo false > ~/.compositor
               #to allow me to hide/unhide the bottom panel when using Do as a Dock or not as a dock....
               gconftool-2 --set --type bool /apps/panel/toplevels/bottom_panel_screen0/enable_buttons false
       else
               echo true > ~/.compositor
               #to allow me to hide/unhide the bottom panel when using Do as a Dock or not as a dock....
               gconftool-2 --set --type bool /apps/panel/toplevels/bottom_panel_screen0/enable_buttons false
 fi
gconftool-2 --set --type bool /apps/metacity/general/compositing_manager $(cat ~/.compositor)
gnome-do

Revision history for this message
Nathan (nathansamson) wrote :

Hi,

I've written a patch for it (based on do-trunk);

Alex Launi (alexlauni)
Changed in do:
status: Confirmed → Fix Committed
Revision history for this message
Jonathan Austin (mailforwho) wrote :

I think this patch introduces some problems of its own. Should I report a new bug?

If I do the following Do crashes with the error below.
1. Start do 1106 with meatcity compositor enabled
2. Open a window (eg Firefox)
3. Toggle the compositor off
5. Summon Do (it turns up in Classic Mode)
6. Toggle Compositor back on
7. Click on an item in Docky that has a window associated with it.

Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
GLib.MissingIntPtrCtorException: GLib.Object subclass Do.Interface.ClassicWindow must provide a protected or public IntPtr ctor to support wrapping of native object handles.
  at GLib.ObjectManager.CreateObject (IntPtr raw) [0x00000]
  at GLib.Object.GetObject (IntPtr o, Boolean owned_ref) [0x00000]
  at Gtk.Widget.buttonpressevent_cb (IntPtr widget, IntPtr evnt) [0x00000]
   at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal)
   at Gtk.Widget.buttonpressevent_cb(IntPtr widget, IntPtr evnt)
   at Gtk.Application.gtk_main()
   at Gtk.Application.Run()
   at Do.Do.Main(System.String[] args)

Hope that helps,
Who

Alex Launi (alexlauni)
Changed in do:
status: Fix Committed → Fix Released
milestone: 0.8.1 → 0.8.2
status: Fix Released → Fix Committed
Changed in do:
status: Fix Committed → Fix Released
Revision history for this message
brianfactors (constitutional-texan) wrote :

I am using 0.8.2 and am still having this problems with compositing.

One definite annoyance got fixed: Do making half your desktop space unusable. Very nice.

But I am still having problems with compositing. My problem is more like Bug #324332; Docky doesn't work on startup. I am using Ubuntu 9.04 - AMD64 and have compiz enabled. Do just doesn't appear and can't be shut down. I have to manually send it the kill signal. When I launch it again, there's no problem. There's only an issue on startup, apparently.

I patched it with a delayed startup script:
           #/bin/bash
           sleep 7 && gnome-do

I just edited "Startup Applications" so that it pointed to this script file instead of just launching Do straight out.

Hope you get a real patch going.

Revision history for this message
Alex Launi (alexlauni) wrote : Re: [Bug 321742] Re: Should detect when Composite has been enabled/disabled, even when gnome-do is running

You're reporting an totally different issue. There's already a bug open for
that, and we're working on it.

--
--Alex Launi

Revision history for this message
Julian Alarcon (julian-alarcon) wrote :

Alex, what is this new bug?? I also have it. Can you give us the URL address or number of the bug?

I'm using gnome-do 0.8.2 on Ubuntu 9.04 "Jaunty" and the workaround of brianfactors works for me.

By the way, there is a little bug inside man pages of gnome-do, they talk about version 0.8.1, but the actual version is 0.8.2.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.