[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: kdenonbeta/uirtk
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-09-12 20:44:28
Message-ID: 200409122044.28803.frans.englich () telia ! com
[Download RAW message or body]

On Sunday 12 September 2004 20:25, Reinhold Kainhofer wrote:
> On Sunday 12 September 2004 22:07, Frans Englich wrote:
> > On Sunday 12 September 2004 19:57, Reinhold Kainhofer wrote:
> > > CVS commit by kainhofe:
> > >
> > > Don't use K* widgets/windows as base class. Will lock up designer...
> >
> > Let me get this straight.. Does the existence of uirtk mean Designer
> > files for about 50 KControl modules can be created in an afternoon?
>
> Yes, more or less. 

And Frans' TODO suddenly became a LITTLE BIT lighter. I owe you a year or work 
or something. Don't remind me at some future KDE meeting -- I would be ruined 
by all the cookies and bears you deserve.

> Modulo the time to fix the bugs in kuiextractor (or 
> uirtk as it is still called. Will be renamed, when we move it to kdesdk).
>
>
> Just install kdenonbeta/uirtk/ and run
>   kuiextractor yourApplication
> (kuiextractor just calls "LD_PRELOAD=libkuiextractor.so yourApplication"),
> and you can extract widgets/dialogs by Ctrl+Shift+Alt and a double-click
> with the right mouse button on the widget. Currently, there's one bug in
> there, where the top-level widget gets assigned the wrong class name, so
> extracting a KCModule will create a top-level widget of class KCModule
> instead of QWidget or QDialog. I don't know when I will find the time to
> fix this.
> See the README file.
>
> There are still some shortcomings, which I haven't yet been able to fix
> (see the TODO file). Also, there might be a few layout levels too much (I
> extract what's really there, not how it might be done simpler), which might
> be simplified in designer later on.
>

Letting the piece mature a little bit, would be in order then(since the 
kcontrol modules isn't a rush). But for KDE 4, that will certainly be an 
amazing time killer.

Thinking out loud: A similar tool for KConfigXT would also be useful. I assume 
the code would be much more dirty and tricky, since it would require parsing 
C++ code, compared to iterating in Qt's introspection. A c++2xml program 
would be a first, very generic and reusable, step(and then an XSL for 
whatever purpose). I'll look into this..


Cheers,
		Frans




[prev in list] [next in list] [prev in thread] [next in thread]