RFC: About custom widgets in designer / KDevelop4

Jonas Widarsson jonas at widarsson.com
Sun Jul 8 11:26:47 UTC 2007

Earlier email on kde-devel triggered me.

On Saturday 07 July 2007, Andreas Pakulat wrote:
> On 07.07.07 13:51:54, dukju ahn wrote:
> > Hi. I happen to write custom widget. That new custom widget has
> > its own .ui, .h and .cpp files. And this widget is contained by other
> > widget using QtDesigner. I used "promote" feature in designer,
> > because custom widget are not displayed in designer unless I
> > write separate plugin (which is difficult).
> I disagree. Its really simple, just create a QDesignerCustomWidgetPlugin
> (exact name may differ) and implement the needed methods (as per
> designer manual). Compile it into a shared object (don't forget the
> Q_.. macro in the .cpp) and put it into a path that is contained in

Hi. I think I have something to share about this subject.
First of all, I'd like to point out that a manual designer custom widget 
plugin enabling process like that is not nearly "really simple" when you 
weren't prepared for it and expected a simple mouseclick or drag and drop or 
something like that, which would by the way more easily fit into the "really 
simple" category. (Man, I am starting to write like the graphics ninja - 
never ending sentences)

I was a little mad at Qt for taking that approach as I was trying that in 
KDE3+Qt3. I found the process too complicated to take the time required to 
use it. Instead I just used those dark anonymous "CustomWidget" placeholders 
available in qtdesigner giving them the corresponding header filenames. Then 
of course, I never saw my application the way it would turn out design wise 
until actually launching it, which makes the qtdesigner a little crippled.

But still I never embarked upon actually compiling those widgets into a plugin 
library. I thought it was too complicated at the time.

End of part one.

In may this year I moved to a new job. Before I was only using open source 
software. Linux, C++ via gcc and PHP for web programming. Now I have got into 
the automation industry where everything is about making things work using 
microsoft friendly solutions. So my first project was to patch up an existing 
industrial software with some home made code written in Visual Basic .NET.

(I could go on about this here but let's cut it to the point.)

Visual Basic is a VERY managed language. And in many ways, you get the feeling 
of fresh air when you realize how much the dev-environment knows about the 
code you are editing. (later finding out that most of the api truly sucks - 
many angry names shouted...) And just this custom widget thing, in Visual 
Studio called "custom controls" is a very painless thing to use.

Here are the steps: 
1. Design a control (which may be inherited from another (multiple inheritance 
is not supported though))

2. Compile the project. VS will detect what you are doing and present the 
control you have compiled in the toolbox for custom controls.

3. Drag the icon for the control onto your Form and use it.

"Really simple" in my opinion.

But then the sunshine ends.
Here's why. Down the road, if you are developing something using visual 
basic .NET, you will get hurt in the way of the project becoming corrupt in 
some way. I have during 40 days experienced several, but specifically one 
major crash where I have had to break the project down to pieces and add them 
back one by one to a clean project. This is where those custom controls I had 
created no longer existed in the project's meta data and I had to put them in 
a separate library and rewrite all code that uses them (which isn't very hard 
That was the latest meta data corruption I had but I expect it to come back 
for me. You should all know that this doesn't happen after a hardware failure 
or something. It just snaps out of the blue, without being directly connected 
to anything you did manually. Not very unexpected though.

I thought Microsoft products would have stabilized during the last five years 
I have been avoiding them. Guess what. They have not...

My reflection is:
Trolltech is actually wise to introduce the "promote to custom widget" 
feature. In many cases I have been customising widgets it was only to change 
the behaviour of an existing one, so the result LOOKS like the original. 
Here, the promotion works well because you don't have to compile a resource 
before being able to use it. Here, you can do the thing without parts of the 
projet depending on the same project.

However, widgets that combine several child widgets with a layout or 
completely custom ones, with their own drawing routines etc. cannot be 
promoted like that easily since they look like nothing else already existing. 
So here, a compiled widget imported into designer makes a lot of sense.

Since designer only produces ui-files, it does not know much (if anything) 
about the compiler or even the platform, CMIIAW.
KDevelop on the other hand, knows everything! ;)

I assume the multiple project support I am starting to hear about can do 
dependencies ? Relying on that:

As KDE devs are way more likely to produce an intelligent result than those 
strapped up in that giant organisation, I would propose that KDevelop does 
this for you. Having a project setting that indicates all widgets meeting the 
requirements should be put in a plugin library that should as automatically 
as possible be made available for qt4 designer.

I am sure this is attractive for some and I am sure some may know better. I 
have personally been thinking about doing this as a type of scripted library 
generation myself, giving the script some input like files to include, 
library to create, path to put it at. That would suffice for me, but what if 
it went into KDevelop? Then it would just be a matter of file permissions to 
make the process automatic altogether. Then we would have the same 
non-brainer procedure as VS.NET has, but hopefully doing it better.

Or maybe I missed an earlier discussion that already dismisses this idea as 

Jonas Widarsson
MSN: jonas at widarsson.com ICQ: 72016688 

More information about the KDevelop-devel mailing list