On Wed, 13 Jul 2011 16:29:11 +0200, Luca Beltrame
<ei...@heavensinferno.net> wrote:
> Hello,
> 
> I'm currently mentoring a season of KDE student to improve KDE's UI
> compiler 
> (pykdeuic4). Currently pykdeuic4[1] monkey patches a compile filter into

> PyQt's UI compiler and overrides some of qtproxies's string functions to

> replace tr() calls with KDE's i18n() functions. 
> 
> This approach has been shown to be fragile, because pykdeuic4 breaks the

> moment PyQt changes, and being a monkey patch, the solution sometimes
> breaks 
> with specific widgets, that get the wrong parameters assigned when being

> compiled. Also, run-time compilation as with PyQt's uic.loadUi() is not 
> possible.
> 
> The plan I and my student came forward to was to create an extension of
> KDE's 
> widgets in the same manner PyQt does, by creating a "kdeproxies" module
> which 
> could be used to override PyQt with KDE widgets. To this aim, we're
> interested 
> in some more information on qtproxies usage in PyQt, and more
importantly
> in 
> how it is used to generate Python objects out of ui files.
> 
> A partial alternative solution, at least for translated strings,  would
be
> to 
> allow, like the C++ ui compiler, the possibility to override tr() and
use 
> kdecore.i18n() from PyKDE4 when compiling widgets (since also Qt widgets
> use 
> i18n() when in a KDE application). 
> 
> If all else fails, extensions could be written as a plugin of uic:
however
> at 
> the time I am not sure it is possible to allow uic to handle other types
> of 
> widgets. 
> 
> Any suggestions on the topic are appreciated.

As I've said before I have no problem in making changes to pyuic4 to make
this easier, but I'd want Simon to be actively involved in any discussions.

Phil
_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Reply via email to