New version of Panel Clock applet

[Kevin Gilbert]

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 
KDE-compliant?

>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 
comment.)

>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 
gratefully received.

>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.

>- Frerich
>
>  
>
Thank you for comments - whilst a little bruising to the ego, they are 
appreciated.

Regards,

Kevin