KDE + Qt/Mac -- how to handle it?

Simon Hausmann hausmann at kde.org
Thu Jan 1 15:13:10 GMT 2004


On Wednesday 31 December 2003 21:04, Benjamin Reed wrote:
> (KDE-Darwin folks, please reply only to the KDE-Darwin list,
> kde-core-devel is moderated...)
>
> As some of you may have noticed, we're starting to hit a point where
> things are working in porting KDE to Qt/Mac.  My question to you is how
> to go about handling the port, and getting it back into the mainline
> sources.
>
> Initially, it was mostly me working, off of Sam Magnuson's original
> port, but now that we've got a few people contributing it's getting
> unwieldy to keep patchsets around.
>
> I'm loathe to just start committing to head because the patches are a
> lot of ugly #ifdef's and unimplemented bits, but at the same time, since
> they're #ifdef'd the only people they really affect are people using
> Qt/Mac.
>
> My thought is there's 2 different ways to go about it:
>
> 1. Just commit to head; it introduces a little bit of entropy but while
> ugly, the patches are pretty safe.
> 2. Make a branch for Qt/Mac development.
>
> I'd rather do 1 just because it's easier, the only reason I'm a bit
> reticent to do so is because we're still in freeze for KDE 3.2.  It's
> not like we're doing anything that isn't already in the tree (Holger
> Schroeder's initial work on chopping out some of the X11-specific stuff
> is already in CVS, and has been for months).
>
> Opinions?  Suggestions?  Massive flame-wars?  =)

I looked through some of the patches (not all of it). Here are some comments:

koffice: I think instead of hardcoding 75 Dpi for non-x11 it'd be better to 
use the QPaintDeviceMetrics API.

kdebase:

There are a lot of patches to kicker, and 'later' on kicker is disabled from 		
compilation (which makes sense for Mac, I guess) . I think just conditionally 
(not unconditinally, like right now in the patch!) disabling kicker is better 
than to also add all the #ifdefs.

There are also a few places where you changed char **argv to char *argv[] . 
Why is that?

In konq_main.cc: You disable konq preloading based on the non-X11 define. Why 
not disable it specifically for mac only, not generally using non-X11 
defines?

In kfmclient.cc: You removed the 'KonquerorIface_stub konqy' variable in the 
x11 #ifdefed part. That will break compilation on X11. (Did you try compiling 
your tree for X11, btw, to see if all the #ifdefs are working?)

There are quite a few #ifdefs in kscreensaver, ksmserver and kstart. Are those 
apps really needed on Mac? How about disabling them from compilation instead?

There are #ifdefs in konq_operations.cc that basically disable dnd completely 
on the Mac. Why is that? Isn't there a way on the Mac to query the status of 
modifies like Ctrl/Shift, etc. at any point? (like the XQueryPointer hack :)

kdelibs:

Why did you add !key.isNull() checks in the X11 specific part of 
KApplication::notify?

There's a superfluous kdDebug() call in kapplication.cpp :)

Why did you add this unconditionally enabled argvexe code in 
KCmdLineArgs::init?

Also you turned some fprintf's in kcmdlineargs into kdDebug() calls. Are you 
sure that's safe? (doesn't kdDebug() open a KConfig object, which then tries 
to initialize KLocale? Might be too early at this point in KCmdLineArgs?)

In kgrantpty.c the unconditinally added 'return 0' looks wrong to me.

You add this 'app bundle' code in quite a few places (kprocess, twice in 
kstandarddirs, kdesu/process.cpp) in the kdelibs patch. Shouldn't this 
duplicated code be centralized somewhere?

That's just some things that I more or less accidentially spotted. I admit I 
didn't really dig into every change, and I also admit that I most likely got 
a few of those things wrong :)

Simon




More information about the kde-core-devel mailing list