KDE interface fails to start: No module named kurllabel

[Martin Pitt]

Since recently, jockey-kde now fails to start due to

  File "kde/jockey-kde", line 464, in <module>
    sys.exit(u.run())
  File "/home/martin/ubuntu/jockey/trunk/jockey/ui.py", line 344, in run
    self.ui_init()
  File "kde/jockey-kde", line 62, in ui_init
    self.mw = uic.loadUi(os.path.join(os.path.dirname(__file__), 'ManagerWindowKDE4.ui'))#, self)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/__init__.py", line 106, in loadUi
    return loader.DynamicUILoader().loadUi(uifile, baseinstance)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/Loader/loader.py", line 22, in loadUi
    return self.parse(filename)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 667, in parse
    actor(elem)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 526, in createUserInterface
    self.traverseWidgetTree(elem)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 504, in traverseWidgetTree
    handler(self, child)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 320, in createLayout
    self.traverseWidgetTree(elem)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 504, in traverseWidgetTree
    handler(self, child)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 328, in handleItem
    self.traverseWidgetTree(elem)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 504, in traverseWidgetTree
    handler(self, child)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 320, in createLayout
    self.traverseWidgetTree(elem)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 504, in traverseWidgetTree
    handler(self, child)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 328, in handleItem
    self.traverseWidgetTree(elem)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 504, in traverseWidgetTree
    handler(self, child)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 157, in createWidget
    self.stack.push(self.setupObject(widgetClass(elem), parent, elem))
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/uiparser.py", line 130, in setupObject
    obj = self.factory.createQObject(clsname, name, args, is_attribute)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/objcreator.py", line 60, in createQObject
    classType = self.findQObjectType(classname)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/objcreator.py", line 70, in findQObjectType
    w = module.search(classname)
  File "/usr/lib/python2.5/site-packages/PyQt4/uic/Loader/qobjectcreator.py", line 46, in search
    self._modules[module] = __import__(module, {}, {}, (cls,))
ImportError: No module named kurllabel

This has worked fine in earlier intrepid versions of python-kde. Was this caused by the recent moving of files in bug 250285? Scott, since you did that change, can you please take a look at this? Runtime libraries shouldn't be in a -dev package. Thank you!

[Scott Kitterman (kitterman)]

As I understand it that is supposed to be used to compile UI files at build
time, not for execution. The equivalent python-kde3 file is in -dev. I'm
not an expert, so I'll ask around a bit.

[Harald Sitter (apachelogger)]

Not a kde4bindings issue at all (I found another one there as well, but that is pretty unrelated ;-)

Alberto's latest changes did some fancy additions/changes to the UI files making it impossible to parse them without python-kde4-dev (quick fix: depend on python-kde4-dev [it depends only on python-qt4 and python-kde4 anyway]). But in general I have to agree with Scott, the .ui files should be parsed at build time rather than at runtime. We would only loose flexibility in development (though I guess one could still make use of uic at development runtime if the parsed .py is not available ), so that disadvantage might actually be a minor one. Advantages are clearly an improved start-up time and the unnecessary dep on python-kde4-dev.

[Harald Sitter (apachelogger)]

By the way, I think compatibility with KDE is kind of broken, or my broken system just refuses to start jockey properly.

[Martin Pitt (pitti)]

Alberto, would you mind having a look at this? If the current way isn't the recommended one, then maybe it should be fixed properly?

[Scott Kitterman (kitterman)]

I also asked apachelogger to look into it too. If the two of you could
coordinate. Unfortunately I'm about to drop offline for a week.

[Alberto Milone (albertomilone)]

I kept using uic.loadUi() because the code was already there and it used to work. Now that pykdeuic4 has been moved into python-kde4-dev I can do what I usually do with QT4/KDE4 application i.e. convert .ui files into .py files at build time. This should be trivial to fix.

I'll post a fix soon.

[Alberto Milone (albertomilone)]

Martin, can you have a look at revision 378 of my branch?
~albertomilone/jockey/jockey-generic-kde

With the new system we don't have to rely on pykdeuic4 and the .py files will be automatically updated to match the changes in the .ui files (at build time). The changes in jockey-kde (the script) are minimal and don't affect its behaviour.

NOTE: revision 378 is meant to be merged with "trunk".

As regards the (already existing) failures in the test-suite (which do not affect the functioning of the program), I haven't worked on them yet because I would like to discuss a few things with you first.

[Martin Pitt (pitti)]

Hi Alberto,

Alberto Milone [2008-09-19 14:35 -0000]:
> Martin, can you have a look at revision 378 of my branch?
> ~albertomilone/jockey/jockey-generic-kde

Thanks for working on this. Some questions:

* jockeyKde/ is entirely autogenerated, right? It shouldn't be in
  revision control. Also, can these be generated in a subdirectory of
  kde/, to not clutter the main source directory?

* You should merge from trunk again, apparently you are missing some
  changes (I suppose that's also the reason for your test suite
  failures)

* generateui is a two-line script which is not called by anything
  else. Can it just go?

* {convert,make}pykde.py do not look jockey specific. Shouldn't they
  be part of python-kde4-dev?

* If we should really keep kdeTools/ in jockey itself, can it be moved
  into kde/ ?

Thank you!

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Alberto Milone (albertomilone)]

On Friday 19 September 2008 17:49:58 Martin Pitt wrote:
> Hi Alberto,
>
> Alberto Milone [2008-09-19 14:35 -0000]:
> > Martin, can you have a look at revision 378 of my branch?
> > ~albertomilone/jockey/jockey-generic-kde
>
> Thanks for working on this. Some questions:
>
> * jockeyKde/ is entirely autogenerated, right? It shouldn't be in
> revision control. Also, can these be generated in a subdirectory of
> kde/, to not clutter the main source directory?
>
Yes, the contents of jockeyKde (i.e. 2 .py files) are generated automatically
at build time. They are real modules which are imported by jockey-kde.

Moving jockeyKde into kde/ (in the source code) wouldn't be a problem.

> * You should merge from trunk again, apparently you are missing some
> changes (I suppose that's also the reason for your test suite
> failures)
>

I did it today but maybe I should start from scratch with a new branch.

> * generateui is a two-line script which is not called by anything
> else. Can it just go?

generateui can be useful when a developer changes the ui files with QtDesigner
and then wants to see the result in the .py file without having to build the
package.

If you want, I can get rid of it and reuse convertpykde.py by simply adding an
if __name__ == "__main__": convertUi()

>
> * {convert,make}pykde.py do not look jockey specific. Shouldn't they
> be part of python-kde4-dev?
>
If you prefer, I can get rid of them by calling /usr/bin/pykdeuic4 with
subprocess in setup.py, it wouldn't be as elegant though (I couldn't check
exceptions in case of malformed .ui files, etc.).

> * If we should really keep kdeTools/ in jockey itself, can it be moved
> into kde/ ?

Yes, sure

Let me know what you think.

Alberto

[Martin Pitt (pitti)]

Alberto Milone [2008-09-19 20:30 -0000]:
> Yes, the contents of jockeyKde (i.e. 2 .py files) are generated automatically
> at build time. They are real modules which are imported by jockey-kde.
>
> Moving jockeyKde into kde/ (in the source code) wouldn't be a problem.

Great.

> > * generateui is a two-line script which is not called by anything
> > else. Can it just go?
>
> generateui can be useful when a developer changes the ui files with QtDesigner
> and then wants to see the result in the .py file without having to build the
> package.
>
> If you want, I can get rid of it and reuse convertpykde.py by simply adding an
> if __name__ == "__main__": convertUi()

Right, and make that executable. One file less to worry about. :-)
However, I don't think it's too bad to just call setup.py build.

> > * {convert,make}pykde.py do not look jockey specific. Shouldn't they
> > be part of python-kde4-dev?
> >
> If you prefer, I can get rid of them by calling /usr/bin/pykdeuic4 with
> subprocess in setup.py, it wouldn't be as elegant though (I couldn't check
> exceptions in case of malformed .ui files, etc.).

Doesn't pykdeuic4 provide error handling/reporting as well? I'd rather
not keep duplicated code in jockey if we can avoid it in any way.
Build tools like those are prone to change over time and should really
be kept centralized.

Thanks!

[Alberto Milone (albertomilone)]

On Sunday 21 September 2008 06:24:50 Martin Pitt wrote:
> Alberto Milone [2008-09-19 20:30 -0000]:
> > Yes, the contents of jockeyKde (i.e. 2 .py files) are generated
> > automatically at build time. They are real modules which are imported by
> > jockey-kde.
> >
> > Moving jockeyKde into kde/ (in the source code) wouldn't be a problem.
>
> Great.
>
> ...
> > If you prefer, I can get rid of them by calling /usr/bin/pykdeuic4 with
> > subprocess in setup.py, it wouldn't be as elegant though (I couldn't
> > check exceptions in case of malformed .ui files, etc.).
>
> Doesn't pykdeuic4 provide error handling/reporting as well? I'd rather
> not keep duplicated code in jockey if we can avoid it in any way.
> Build tools like those are prone to change over time and should really
> be kept centralized.
>

Ok, the result is in revision 381.

NOTE: currently I have to call pykdeuic4 with Python because calling it
directly triggers a bug:

$ pykdeuic4
bash: /usr/bin/pykdeuic4: Permission denied

Maybe this should be discussed in another bug report.

Alberto

[Martin Pitt (pitti)]

I merged your patch and cleaned it up a bit (proper handling in setup.py, and I finally made up my mind where the files should live). Thanks, Alberto! I'll mark that as a dup of the apport crash, since that already has duplicates.

[Martin Pitt (pitti)]

Alberto Milone [2008-09-21 10:18 -0000]:
> NOTE: currently I have to call pykdeuic4 with Python because calling it
> directly triggers a bug:
>
> $ pykdeuic4
> bash: /usr/bin/pykdeuic4: Permission denied

Indeed, it's a symlink to a .py file which is not installed as
executable. That should be fixed in python-kde4-dev.