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
> QT_PLUGIN_PATH
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
in VS.NET OTOH).
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.
Discussion:
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
bad.
--
Jonas Widarsson
MSN: jonas at widarsson.com ICQ: 72016688
More information about the KDevelop-devel
mailing list