DockbarX launchers disappear

Bug #579029 reported by Derek
40
This bug affects 8 people
Affects Status Importance Assigned to Milestone
DockbarX
Incomplete
High
Unassigned

Bug Description

Symptoms:
------------------------------

- Launchers disappear
- Open applications not reflected in launchers

Reproduce:
------------------------------

- Start/end DockbarX

Affected Versions:
------------------------------

- 0.24.x
- 0.30.x.

Comments:
------------------------------

I noticed that the "launchers" GConf key is changed when this happens. No idea why only certain values are removed from the list.

I've got it printing to a terminal this launch. Will see if I can generate a log for you.

Tags: dockbarx
Revision history for this message
Derek (derek-incandetech) wrote :
Revision history for this message
Derek (derek-incandetech) wrote :

After closer review, it appears that the fifth launcher (see above screenshot) is there...somewhat. There's no icon and it doesn't take up the amount of space it should. The only reason I can tell it's there (or so it seems) is that if I right click in the space where it should be its menu pops up (in this case for Firefox). I can then unpin it, but after a refresh it "reappears" in its semi-hidden state.

Revision history for this message
Derek (derek-incandetech) wrote :

The following error is generated with mouse activity over the hidden launcher:

Traceback (most recent call last):
  File "/usr/bin/dockbarx.py", line 3276, in on_button_mouse_enter
    self.update_state()
  File "/usr/bin/dockbarx.py", line 2754, in update_state
    surface = self.icon_factory.surface_update(self.state_type)
  File "/usr/bin/dockbarx.py", line 632, in surface_update
    surface = f(surface, **args)
  File "/usr/bin/dockbarx.py", line 893, in command_get_icon
    if self.icon \
AttributeError: IconFactory instance has no attribute 'icon'

Revision history for this message
Matias Särs (msevens) wrote :

Thanks for the report. I will look into it.

Changed in dockbar:
importance: Undecided → High
Revision history for this message
Matias Särs (msevens) wrote :

Ok, I've started with this bug. Do you get any error message when you start dockbarx or is the one on mouse over the only one you get?

Revision history for this message
Derek (derek-incandetech) wrote :

The only output I get (on startup) is:

** (dockbarx.py:7254): WARNING **: Trying to register gtype 'WnckWindowState' as flags when in fact it is of type 'GEnum'
** (dockbarx.py:7254): WARNING **: Trying to register gtype 'WnckWindowActions' as flags when in fact it is of type 'GEnum'
** (dockbarx.py:7254): WARNING **: Trying to register gtype 'WnckWindowMoveResizeMask' as flags when in fact it is of type 'GEnum'
/usr/bin/dockbarx.py:4821: Warning: g_set_prgname() called multiple times
  "dockbar applet", "0", dockbar_factory)
Dockbarx init
Dockbarx reload
Opened window matched with gio app on id: firefox
Opened window matched with gio app on id: opera
Opened window matched with gio app on id: gnome-panel

I'm thinking that's all normal, correct?

What I'm noticing is that once I add Firefox as a launcher things start getting corrupted. The GNOME menu launcher for Firefox is not showing the correct icon on my install. Viewing the launcher ("firefox.desktop") in a text editor reveals:

Icon=firefox-3.5

Changing that to:

Icon=firefox

...obviously fixes that issue. I believe this icon issue is the result of this system using the "Mozilla Firefox Stable" PPA, but that's largely irrelevant.

So, I'm thinking that DockbarX doesn't handle missing icons correctly. I'm guessing once it encounters a launcher with a missing icon it fails, and stops rendering all remaining launchers. I'd argue rendering the GNOME/Ubuntu "unknown" icon (or whatever it's called) icon would be a suitable solution.

I'm thinking this makes sense; it seems like something I'd overlook if I was coding something similar. Why the GConf "launchers" key is getting modified in the process...I don't have a clue.

Revision history for this message
Matias Särs (msevens) wrote :

You are correct. There was a bug in the way dockbarx handled missing icons, which I actually fixed yesterday when hunting another bug. Dockbarx is supposed to render the "missing" icon (I believe that was it's name) and should do so now, once again.

Your reasoning makes sence in all parts, the only custion is: Where are the error messages?? Dockbarx can't stop rendering the remaining launchers because of an missing icon without some error messages, the process can't have been halted in the middle without any python error.

In what way are the launchers modified?

Revision history for this message
Matias Särs (msevens) wrote :

*question

Revision history for this message
Matias Särs (msevens) wrote :

Derek, could you answer the last question?

Matias Särs (msevens)
Changed in dockbar:
status: New → Incomplete
Revision history for this message
Matias Särs (msevens) wrote :

Is this bug fixed now?

Revision history for this message
dRewsus (drewsus) wrote :

Not as far as I can tell. Periodically I lose icons for:
gnome mplayer
nautilus (sparatic)
emesene contact list
rhythmbox
gedit
and more

Usually a "killall gnome-panel" or refreshing the theme will bring it back but not always

Revision history for this message
dRewsus (drewsus) wrote :

the above is in regards to 0.40

Revision history for this message
Matias Särs (msevens) wrote :

Run dockbarx in window again and tell me if there are any errors. You probably have to keep it running until some icon disappears or any icon fails to appear before any useful errors message turn up.

dockbarx_factory.py run-in-window

Revision history for this message
TeRrOkToR (terroktor) wrote :

Hi admins....

I'm using dockbarx v 0.47 and get similar problem... my dockbar dont start at startup... only after refresh it, and every reboot it disappears...

my dockbarx_factory.py run-in-window:

DockbarX 0.47
DockbarX init

** (dockbarx_factory:1769): WARNING **: Binding '<super>0' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>1' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>2' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>3' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>4' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>5' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>6' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>7' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>8' failed!

** (dockbarx_factory:1769): WARNING **: Binding '<super>9' failed!
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/dockbarx/dockbar.py", line 189, in __load_on_realized
    self.load()
  File "/usr/lib/pymodules/python2.7/dockbarx/dockbar.py", line 257, in load
    name = u""+app.get_name().lower()
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 26-27: invalid continuation byte
./dockbarx_factory:55: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  gtk.main()

(dockbarx_factory:1769): Bonobo-WARNING **: Never got frame, control died - abnormal exit condition

Is there way to refresh dockbarx automatically every startup ?

How to fix it ?

PS: I'm using Ubuntu 11.04 us.iso-8859-1 because my work !

Tks a lot !!!

Revision history for this message
Rob McCathie (korrode) wrote :

It would appear this bug is still very much present in the current 0.90.3.

I would love to see this fixed, i consider the severity of as bringing me to the borderline of not using it at all, as such if there is anything i can do to provide debug or other info please let me know.

Revision history for this message
Matias Särs (msevens) wrote :

This bug thread is way too old and quite mixed up. I believe it contains at least three fixed bugs. Rob are you sure your bug is related to the ones mentioned here? Do you get the same error messages? Or do you perhaps use multiple monitors? That would be another bug, that I will look into when I get virtualbox up and running with virtual dual monitors.

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.