Dockbarx fails to load

confirmed by a number of people on the internet.

I've asked this elsewhere, but I could ask here as well... Is this happening only on karmic or are lucid affected as well?

lucid as well. This is a curious issue as it occurs some boots, and some boots does not. 90% of boots it does occur.
I suspect that this is caused by the dockbarx server taking longer than expected to start when all the session programs are starting in parallel. Maybe it would be possible to reduce the amount of work done when instantiating dockbax, and to do that after returning the dockbarx server?

That sounds logic. I committed a possible fix. Reload is loaded first when everything is idle. Does it work?

That didn't work. I am investigating making the Dockbar class constructor short, for example by loading settings later than in the constructor, so that Dockbarx does not need the disk and returns quickly from dockbar_factory so that bonobo does not complain about it. No luck so far. I don't even see the dockbarx handle before the error pops up. At that point networkmanager, clock, gnome-globalmenu and the Ubuntu main menu are already up. I wonder why dockbarx is slower than the others?
It might also be useful to look at other python applets...

Also, I discovered that a sure way to cause this error is to put a sleep of for example 10 seconds in the beginning of dockbarx, just after from time import sleep. Then the error occurs every start of dockbarx, not just on bootup.

Ok, now I've pushed pretty much everything (including most of the imports) to after the applet is done. Does it work now? If it doesn't, try change line 3905 "gobject.idle_add(self.idle_init)" to "gobject.timeout_add(20000, self.idle_init)" and tell me if that works any better.

Without the timeout, no luck.
With it, no luck either.
I was thinking if it's possible to somehow run the gnome panel itself under gdb and catch the communication problem.

I get this on every boot on the eee pc. I just removed everything from the gnome panel, except dockbarx and ubuntu menu. No luck, I still get this, and dockbarx loads for a really long time.

I just loaded dockbarx.py on a VT just when my GNOME session was starting, and I didn't get the error. However that dockbarx instance did not log anything.

Ok, this is not a fix, but hopefully it would give some information of where the bug is. The handle is loaded and there's a new option ("New") in the applet's popup menu that loads the whole thing. Does it still crash when using this?

=== modified file 'dockbarx.py'
--- dockbarx.py 2010-04-28 16:19:05 +0000
+++ dockbarx.py 2010-04-28 19:23:08 +0000
@@ -3891,18 +3891,19 @@
                 <menuitem name="About Item" verb="About" stockid="gtk-about" />
                 <menuitem name="Preferences" verb="Pref" stockid="gtk-properties" />
                 <menuitem name="Reload" verb="Reload" stockid="gtk-refresh" />
+ <menuitem name="Load" verb="Load" stockid="gtk-new" />
             </popup>
             """

             self.pp_menu_verbs = [("About", self.on_ppm_about),
                                   ("Pref", self.on_ppm_pref),
- ("Reload", self.reload)]
+ ("Reload", self.reload),
+ ("Load", self.idle_init)]
             self.applet.setup_menu(self.pp_menu_xml, self.pp_menu_verbs,None)
             self.applet_origin_x = -1000 # off screen. there is no 'window' prop
             self.applet_origin_y = -1000 # at this step
             self.applet.set_background_widget(applet) # background bug workaround
             self.applet.show_all()
- gobject.idle_add(self.idle_init)
         else:
             self.container = gtk.HBox()
             self.orient = "h"
@@ -3910,7 +3911,7 @@

- def idle_init(self):
+ def idle_init(self, event=None, data=None):
         # Import all stuff.
         later_imports()
         # self.dragging is used to tell functions wheter

I investigated this another way: from near-zero. I tried the sample python applet in the docs of python-gnomeapplet. I also made a very small version of dockbarx, in the hope that it would give insight into why it does not work. Here is a dockbarx factory class that does not cause the error.

#!/usr/bin/python

# Copyright 2008, 2009, 2010 Aleksey Shaferov and Matias Sars
#
# DockBar is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# DockBar is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with dockbar. If not, see <http://www.gnu.org/licenses/>.

import pygtk
pygtk.require('2.0')
import gtk
import gobject
import gnomeapplet
import sys

class DockBar(gobject.GObject):
    __gsignals__ = {
        "db-move": (gobject.SIGNAL_RUN_FIRST, gobject.TYPE_NONE,()),
    }
    def __init__(self,applet):
        gobject.GObject.__init__(self)
        print "Dockbarx init"
        self.applet = applet

        #--- Applet / Window container
        if self.applet != None:
            self.applet.set_applet_flags(gnomeapplet.HAS_HANDLE|gnomeapplet.EXPAND_MINOR)
            if self.applet.get_orient() == gnomeapplet.ORIENT_DOWN or applet.get_orient() == gnomeapplet.ORIENT_UP:
                self.orient = "h"
                self.container = gtk.HBox()
            else:
                self.orient = "v"
                self.container = gtk.VBox()
            self.applet.connect("change-orient",self.on_change_orient)
            self.applet.connect("delete-event",self.cleanup)
            self.applet.add(self.container)
            self.applet.connect("size-allocate",self.on_applet_size_alloc)
            self.applet.connect("change_background", self.on_change_background)
            self.pp_menu_xml = """
            <popup name="button3">
                <menuitem name="About Item" verb="About" stockid="gtk-about" />
                <menuitem name="Preferences" verb="Pref" stockid="gtk-properties" />
                <menuitem name="Reload" verb="Reload" stockid="gtk-refresh" />
            </popup>
            """

            #self.pp_menu_verbs = [("About", self.on_ppm_about),
                                  #("Pref", self.on_ppm_pref),
                                  #("Reload", self.reload)]
            #self.applet.setup_menu(self.pp_menu_xml, self.pp_menu_verbs,None)
            self.applet_origin_x = -1000 # off screen. there is no 'window' prop
            self.applet_origin_y = -1000 # at this step
            self.applet.set_background_widget(applet) # background bug workaround
            self.applet.show_all()
            #gobject.idle_add(self.idle_init)
        else:
            self.container = gtk.HBox()
            self.orient = "h"
            #self.idle_init()

    def cleanup(self,event):
       ...

I'm wondering if the lenght (size) of the script has anything to do with the bug. The test I suggested before would crash if the lenght is the reason but wouldn't crash if only the time it takes to load is the reason (assuming that the lenght isn't the reason for the longer time).

I tried your version just now, and I get the same error.
However: If I remove the line:
self.applet.setup_menu(self.pp_menu_xml, self.pp_menu_verbs,None)
dockbarx loads! hooray! pity about the lack of the menu.
However, I had some changes from
So I went on to defer the menu loading instead of removing it, with gobject.idle_add, but that caused the error too.
So I tried gobject.timeout_add with 20000. That did not work either. I don't know why this is.
No matter what I do, that line causes the error.

So if you revert back to rev. 169 and remove self.applet.setup_menu(self.pp_menu_xml, self.pp_menu_verbs,None) it still works? If so, you've done a great job bug hunting!

I removed this line from rev 170, to make that clear.

Could you try with 169, just to be sure?

Removing the same line from 171 with this patch also allows dockbarx. to load.
--- dev/dockbarx/dockbarx.py 2010-04-28 23:20:12.117796000 +0300
+++ /usr/bin/dockbarx.py 2010-04-28 23:22:50.718825611 +0300
@@ -3992,7 +3992,7 @@
             self.pp_menu_verbs = [("About", self.on_ppm_about),
                                   ("Pref", self.on_ppm_pref),
                                   ("Reload", self.reload)]
- self.applet.setup_menu(self.pp_menu_xml, self.pp_menu_verbs,None)
+ #self.applet.setup_menu(self.pp_menu_xml, self.pp_menu_verbs,None)
             self.applet_origin_x = -1000 # off screen. there is no 'window' prop
             self.applet_origin_y = -1000 # at this step
             self.applet.set_background_widget(applet) # background bug workaround

I seem to have fixed the bug by loading the menu early, right in the beginning of the Dockbar class constructor.
See attached patch, applies to bzr rev 171.

169 without modifications has the error (we probably knew that).
My early menu patch does not help when applied to 169.
Removing the offending line
self.applet.setup_menu(self.pp_menu_xml, self.pp_menu_verbs,None)
works about 50% of the time.

I have much better success with 170/171.

For 169, this patch seems to do the trick.
I add the menu early, and don't wait in the loop in the end of the constructor before reload.

I just got another failure on a second login after boot.
169 seems not to work so well afterall...

I used 169 as a base and separated it into the dockbarx module and the launcher/factory. This has not failed yet, and I have tested it many times. Other applets, for example the deskbar applet, use a similar format: a launcher of less than 200 lines, and multiple imported modules.

I moved dockbarx.py to /usr/lib/python2.6/dist-packages. After that, it can be imported with import dockbarx.
I call the following factory class dockbarx_factory.py:

#!/usr/bin/python

# Copyright 2008, 2009, 2010 Aleksey Shaferov and Matias Sars
#
# DockBar is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# DockBar is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with dockbar. If not, see <http://www.gnu.org/licenses/>.

import pygtk
pygtk.require('2.0')
import gtk
import gobject
import gnomeapplet
import sys
import dockbarx

def dockbar_factory(applet, iid):
    dockbar = dockbarx.DockBar(applet)
    applet.set_background_widget(applet)
    applet.show_all()
    return True

if len(sys.argv) == 2 and sys.argv[1] == "run-in-window":
    dockbarwin = dockbarx.DockBarWindow()
    dockbarwin.main()
else:
    gnomeapplet.bonobo_factory("OAFIID:GNOME_DockBarXApplet_Factory",
        gnomeapplet.Applet.__gtype__,
        "dockbar applet", "0", dockbar_factory)

Now, this factory class needs to be referenced in the bonobo server description:

--- GNOME_DockBarXApplet.server 2010-04-29 00:00:04.496690000 +0300
+++ GNOME_DockBarXApplet.server.modular 2010-04-29 01:35:30.285671672 +0300
@@ -1,5 +1,5 @@
 <oaf_info>
-<oaf_server iid="OAFIID:GNOME_DockBarXApplet_Factory" type="exe" location="/usr/bin/dockbarx.py">
+<oaf_server iid="OAFIID:GNOME_DockBarXApplet_Factory" type="exe" location="/usr/bin/dockbarx_factory.py">

     <oaf_attribute name="repo_ids" type="stringv">
         <item value="IDL:Bonobo/GenericFactory:1.0"/>

And that's it.

Really great work, thanks!

I will now (or soon anyway, I'm busy moving IRL this weekend) do what I've been thinking about doing for a while: splitting up dockbarx in smaller modules and adding a setup.py for installation.

I dont know if this can help but I could reproduced the bug in a VM with ubuntu 10.4 and undo it again.

repruduce the bug:
Add Dockbarx to panel.
Open gnome-session-properties, save the current session and reboot.
After reboot i get the same bug as in the Description above.

undo the bug:
go to /home/username/.config/gnome-session and remove the folder "saved-session".
After reboot Dockbarx starts normal again without errors in xsession-errors.

I hope this will help

qweru, I was able to consistently reproduce the bug with my separate factory based dockbarx using your instructions.
I was also unable to reproduce the original bug with a cleared gnome-session. This seems to be a definitive fix.

However, I wonder why my technique fixed this also for my previous saved session, and why did my saved session intermittently cause this issue?

Also, why does a saved session cause this, but not for other applets? Seems curious.
With a saved session, my login takes much longer. Perhaps time is a factor.
I put sleep(10) in the beginning of dockbarx code, but I still could not reproduce the bug with a clear session.

Your fix is so far the simplest and most functional.

Sounds like this bug is on its way to getting resolved, but I'll just chime in that this bug is not exclusive to Ubuntu. I'm experiencing it on EB4 beta (previously Eeebuntu), which is Debian-based. This is with Dockbarx version 0.30.

m4cph1sto, did you try go to /home/username/.config/gnome-session and remove the folder "saved-session", as qweru suggested? Did it help?

Matias, removing the saved-sessions folder does not fix the problem for me. Also, I get the error when initially adding dockbarx to the panel, and unlike the original poster, killall gnome-panel does not get dockbarx to load, it just reports the error again.

I'm guessing your bug isn't at all connected to this one. Run dockbarx in window and see if there is any errors (in a terminal: dockbarx.py run-in-window).

Ah-ha! I did not have python-wnck installed, and without it I was getting the exact same error as the OP. Installing python-wnck solved the problem. So I'm not experiencing this same bug in Debian. Maybe it is Ubuntu-specific. My situation was related to bug # 540950 which I filed, in that python-gnome2-desktop no longer exists in Debian sid, and instead other packages are required for Dockbarx to work: probably python-wnck and python-gnomeapplet, as you suggested.

" go to /home/username/.config/gnome-session and remove the folder "saved-session" " and removing /home/chips/.gconf/apps/panel/applets. It was help for me!

Hi!
After installing of version 0.39-0~ppa2 dockbarx applet fails to load during logon as soon as when I try to add it to panel again with message:

The panel encountered a problem while loading "OAFIID:GNOME_DockBarXApplet"
and message in .xsession-errors:

** (gnome-panel:23173): WARNING **: panel-applet-frame.c:1273: failed to load applet OAFIID:GNOME_DockBarXApplet:
System exception: IDL:Bonobo/GeneralError:1.0 : Child process did not give an error message, unknown failure occurred
I've tried all the workarounds described in this bug without success.

Version 0.39 fails to load here also in lucid

jan2ary & ValentinV,

Yours is a completely different bug resulting from python being installed in the wrong place. It's already fixed as of 0.39-0~ppa3. Please run 'sudo apt-get update && sudo apt-get upgrade'.

For any further discussion about your bug, please open a separate bug report.

Using EB4 Beta (Debian-based): prior to upgrading to 0.39-0~ppa3, dockbarx would sometimes fail to load, sometimes not, but never give an error. A simple "killall gnome-panel" would get dockbarx to load fine. Today I did an apt-get upgrade to 0.39-0~ppa3 and now I get the dreaded "Panel encountered a problem while loading ..." error. killall gnome-panel just gives the same error.

Do 0.39-0~ppa3 remove the file /usr/bin/dockbarx.py? That file could be be the reason for the errors if it's not removed.

Oh, I see. You are talking about that dialog box. Does "dockbarx_factory.py run-in-window" tell you anything. It would be better to make a new bug report thogh, since this is a separate bug.

The file /usr/bin/dockbarx.py is gone. Running dockbarx_factory.py run-in-window give the following message:

Traceback (most recent call last):
  File "/usr/bin/dockbarx_factory.py", line 26, in <module>
    import dockbarx.dockbar
ImportError: No module named dockbarx.dockbar

Anyway, I filed a new bug report for this:
https://bugs.launchpad.net/dockbar/+bug/586798

Is this bug finally gone for real now? Can I finally file it as Fix released?

On my Eee with 0.39.2 Dockbarx loads fine every time now.

I just updated to 0.39.3 and it gave me that error. I did all the things mentioned above and nothing helped. I reverted to 0.39.2 by using dockbarx_0.39.2-0~ppa0_all.deb from /var/cache/apt/archives/ and it works like it did before.

What error? The one m4cph1sto had?

Try to do a complete removal in synaptic and then upgrade, if you didn't try that already.

I just updated to dockbarx_0.39.3-0~ppa0_all.deb via the PPA am now getting this error when running dockbar_factory.py:

** (dockbarx_factory.py:3221): WARNING **: Trying to register gtype 'WnckWindowState' as enum when in fact it is of type 'GFlags'

** (dockbarx_factory.py:3221): WARNING **: Trying to register gtype 'WnckWindowActions' as enum when in fact it is of type 'GFlags'

** (dockbarx_factory.py:3221): WARNING **: Trying to register gtype 'WnckWindowMoveResizeMask' as enum when in fact it is of type 'GFlags'
Traceback (most recent call last):
  File "/usr/bin/dockbarx_factory.py", line 26, in <module>
    import dockbarx.dockbar
  File "/usr/lib/python2.6/dockbarx/dockbar.py", line 31, in <module>
    import keybinder
ImportError: No module named keybinder

I found the problem. It looks like the latest version of the package needs to depend on python-keybinder. For those having issues loading 0.39.3, run this command to fix it:

 sudo apt-get install python-keybinder

Thanks for that, it really get on my nerves to use the standard bar :)

Yup, that works. cheers..

Installing python-keybinder works for me too. Thanks

@Eemil and/or qweru
I changed the startup sequence to get the multiple monitor support to work (I needed to get the container realized before loading the group buttons). This change has probably speeded up the process slightly, instead of the opposite. Regardless, could you confirm that this bug hasn't returned because of the change, please?

With latest bzr, I have no problem loading dockbarx on bootup. However, if I load it by killing gnome-panel, it will show up empty and I need to right-click and refresh.

Also on startup now, dockbarx will show up empty and I need to right-click and refresh.

Gnome panel applets, do they ever behave as you expect?

I implemented it the ugly way (gobject.timeout_add) instead. Seems to work alright here. Can you confirm?

I am getting this error when adding dockbarx to panel.
Initially, I got the error on reboot and dockbarx failed to load.
I updated from 0.39.4 to 0.39.5 with no change in result.
Error:
"The panel encountered a problem while loading "OAFIID:GNOME_DockBarXApplet"."

Here is dockbarx in window:
** (dockbarx_factory.py:2636): WARNING **: Trying to register gtype 'WnckWindowState' as enum when in fact it is of type 'GFlags'

** (dockbarx_factory.py:2636): WARNING **: Trying to register gtype 'WnckWindowActions' as enum when in fact it is of type 'GFlags'

** (dockbarx_factory.py:2636): WARNING **: Trying to register gtype 'WnckWindowMoveResizeMask' as enum when in fact it is of type 'GFlags'
Traceback (most recent call last):
  File "/usr/bin/dockbarx_factory.py", line 26, in <module>
    import dockbarx.dockbar
  File "/usr/lib/python2.6/dockbarx/dockbar.py", line 36, in <module>
    from groupbutton import *
  File "/usr/lib/python2.6/dockbarx/groupbutton.py", line 39, in <module>
    import zg
  File "/usr/lib/python2.6/dockbarx/zg.py", line 40, in <module>
    result_type=datamodel.ResultType.MostRecentSubjects,
NameError: name 'datamodel' is not defined

I was upgraded dockbarx to version 0.39.6.1-1~ppa2 , and it took fail to load:

The panel encountered a problem while loading "OAFIID:GNOME_DockBarXApplet".

[majesty][~]$ dockbarx_factory.py run-in-window
Traceback (most recent call last):
  File "/usr/bin/dockbarx_factory.py", line 26, in <module>
    import dockbarx.dockbar
ImportError: No module named dockbarx.dockbar

I got the datamodel problem as well, but I thought it was a conflict between the bzr version and the release. It seems not.

Great, having a bug named dockbarx fails to load ensures that you get every bug report in here for completely different bugs in here...

@finny388
That problem is fixed x.0.36.6 I accidentally made zeitgeist mandatory in x.0.36.5.

@majesty
There seems to have been some problems in with ~ppa2 and I see that ~ppa4 is about to be built, just wait a few hours (or downgrade for the time being).

@Eemil
In what version did you get datamodel problems?

I got this:
File "/usr/lib/python2.6/dockbarx/zg.py", line 40, in <module>
    result_type=datamodel.ResultType.MostRecentSubjects,
NameError: name 'datamodel' is not defined
in 0.39.5.1-0~ppa1.

Hi !

I'm a

Hi !

I'm a new user, and I didn't read the full thread to be honest. I have this bug to (crash on login). The only thing I found that (I think) fixed the problem for me is to erase the .desktop file in ~/.config/saved-session/ that refers to dockbarX.

I haven't read the full thread either, but I'm on the dockbarX PPA and have started getting this error recently. Most times I login I get it and have to manually add the dockbar again. Then the times when it does work on login there are 2 dockbars and I have to remove one.

The last commit should hopefully improve this again. Now most stuff is loaded after dockbarx is realised.

Please reopen if this bug persists.