kdelibs/win32 : kdecore patch

[Holger Schroeder]

On Wednesday 08 September 2004 12:50, David Faure wrote:
> On Tuesday 07 September 2004 23:25, Holger Schroeder wrote:
> > hi,
> >
> > On Thursday 02 September 2004 18:44, David Faure wrote:
> > > On Thursday 02 September 2004 18:15, Jarosław Staniek wrote:
> > > > 2. http://www.iidea.pl/~js/qkw/upload/kdecore.diff.tar.gz
> > > >
> > > > kdecore/ patches (about 100 files, not all)
> > > >
> > > > Please review
> > >
> > > -#if defined Q_WS_X11 && ! defined K_WS_QTONLY
> > > +#if (defined Q_WS_X11 || defined Q_WS_WIN) && ! defined K_WS_QTONLY
> > >  #include <kstartupinfo.h>
> > >  #endif
> > >
> > > Who introduced the K_WS_QTONLY? Ah, Holger. Holger: does it make any
> > > sense to keep those? As shown above, they basically break things for
> > > others, since e.g. kstartupinfo isn't really x11-dependent in
> > > itself.... js: you don't use K_WS_QTONLY, right? If nobody does, I
> > > think we should clean this up.
> >
> > when kde will run under x11/windows/mac os, this K_WS_QTONLY will not be
> > needed any more, that is right. my intention when i introduced it was,
> > that i wanted to be able to have a kde that was only dependant on qt and
> > not on x11.
>
> But that's not the case right now, and it's rather an impossible goal (see
> Harri's post).
>
well, there are some x11-dependent parts, which are nice to have, but not 
really neccessary, like transparency in konsole, or shadows of windows in the 
keramik theme.

i wanted to make these dependencies optional.

> > this should make the porting process easier.
>
> Actually, it doesn't. The unclear semantics of QTONLY make the porting
> process more difficult.
>
> Example taken from kiconview.cpp:
> #if defined Q_WS_X11 && ! defined K_WS_QTONLY
>   //FIXME(E): Implement for Qt Embedded
>   uint keybstate = KApplication::keyboardModifiers();
>   QIconViewItem* previousItem = currentItem();
> #endif
>
> 1) there's nothing X11 specific about that code.
> It's the current implementation of keyboardModifiers() that is
> x11-specific, but it's easy enough to implement it for win32.
> 2) there's nothing qt-only specific in that code - I don't even understand
> the #if. 3) the comment is confusing (qt embedded? well it needs to be
> implemented for all...) OK maybe it's an example where the code was changed
> after the #if was added, but still - the QTONLY stuff is only disabling
> some stuff, whereas correct win32/macos ports include actually implementing
> the stuff that is different from x11.
>
well, iirc, i didn´t add the original #ifdef Q_WS_X11, but i only added the 
QTONLY part. i think the whole ifdef could be removed.

> > when kde will run fine under windows
>
> That's exactly what js is working on, the right way; the QTONLY defines
> only add to the mess.
>
> > i will be fine with removing the  #if  defined K_WS_QTONLY from the
> > sources...
>
> How about allowing js to remove them as part of his win32 port?

this is ok with me. unfortunately i am quite busy at university at the moment, 
so i have not so much time to help on this in the next month(s)...