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 widarsson.com ICQ: 72016688
_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|
I'm not sure though it'll happen for 4.0, because we need to
save
something for KDevelop4.1 and there's already plenty of
things to do for
4.0.
Andreas
--
You are destined to become the commandant of the fighting
men of the
department of transportation.
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel