New version of Panel Clock applet
kev.gilbert at optusnet.com.au
Fri Jan 9 09:23:57 GMT 2004
Frerich Raabe wrote:
> Here we go:
>1.) The tarball has a little unfortunate layout (I was surprised that I
> suddenly had a /home/frerich/src/usr/local/kde3../applets/clock directory)
Sorry, but this is my first hack at KDE. What should I have done?
>2.) It wouldn't link for me out of the box, I had to add $(LIB_KFILE) to the
> LIBADD line (since it uses KURLRequester). Also, I had to add clockdate.cpp
> to the SOURCES.
The whole Makefile thing has been the bane of my existence during this
episode. I do not know how to generate a Makefile from a Makefile.am.
I've been hand-tailoring the generated Makefile - a _very_ time
consuming and error prone exercise! What I'm missing is a 'configure.in'
file (a possibly a lot of other things). How do I generate one that is
>3.) I noticed that you have many QObject derived classes (for instance the
> ClockDate class) which don't have the Q_OBJECT macro (and which hence also
> didn't include any .moc file). This should be fixed.
This is just another example of my newbie-ness. I was under the
impression that any class derived from a QObject-derived class didn't
require that macro. I'll research this matter and make the appropriate
changes. But - if I've done the wrong thing, why does it work?
>4.) There are many little C++ style problems, like not passing stuff as
> reference-to-const to functions (i.e. "void f(QFont)", passing constant
> values to functions (I saw "void f(const double)" somewhere), constructors
> which use assignment instead of initialization.
I'm not sure what you are referring to here. Could you give me a
specific example of what you want? Obviously my code is OK from a C++
view-point but not from the KDE view-point. (BTW - the "const double"
you refer to, it was in the "PlainClock" class, has been deleted in the
version currently under construction - but this does not invalidate you
>5.) The configuration dialog is a beast, this definately needs some trimming!
Yes, that has been a very common comment from the kde-devel folks. All I
can say is (1) I'm good at the technical stuff but, obviously, lousy at
the user-interface design stuff; and (2) the number of tabs has been
reduced to 3.
>6.) It doesn't seem to honour the current configuration file format (I think
> none of my settings have been honoured)
How important is this?
Whilst this is not a reason / excuse for my code, I've always had
problems upgrading from one version of KDE to another. This includes
loss of most /all settings: Desktop, Panel options & etc. I've come to
accept this as the price of upgrading from one version of KDE to another.
If migration of the users current settings is important (and, yes, it
should be), I'll implement some form of migration facility.
>7.) AFAICS it does not employ any of the fine new technologies which will be
> introduced with KDE 3.2 (KConfig XT comes to mind).
KConfig XT? Is this the *.kcfg derived code?
If so, I tried to modify the existing code to do what I wanted - without
success. For example, how do I implement a QComboBox that has dynamic
contents. The type "Enum" doesn't work (obviously) and all my attempts
to use a type of "String" also led to failure. I put out a request to
the kde-devel list for help on this matter and received no useful
advice. I've also searched for some documentation of this facility but
with out success. I even looked at the compiler's source code for help -
and it was as a result of this that I decide to discard that whole
approach and write my own code.
Any help that the KDE developers can give me in this regard would be
>That's where I stopped looking. I think this will need some serious cleanup
>before it can go in.
Another version is in works - any further input you (and your
colleagues) give me will be incorporated in that new version.
Thank you for comments - whilst a little bruising to the ego, they are
More information about the kde-core-devel