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

[Benjamin Reed]

Simon Hausmann wrote:
> 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.

Yeah, the hardcoding is just a first step to get it running.

I started looking into the QPaintDeviceMetrics stuff but haven't grok'd 
it enough to implement anything.  I'm really not much of a coder, 
although I can #ifdef the hell out of something....  =)

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

Yeah, I got halfway through and realized there's really no point in 
finishing getting kicker to compile, so I just disabled it.  =)

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

Good question, I don't remember why I did 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?

OK.

> 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?)

Must have been a slip.  Haven't done an X11 build with this yet, it's on 
my TODO though once things have settled a bit, and certainly before any 
big commits to the official tree would happen.

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

Probably not needed, no.  Although I suppose kstart could be handy.

One of the things on our TODO is to use --enable-mac for determining 
whether to disable compilation of some stuff (right now we're just 
hard-coding the DO_NOT_COMPILE bits without any conditionals).  A lot of 
that stuff will get cleaned up then.

> 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 :)

Eventually.  Currently hotkey support is pretty messed in general. 
Right now it thinks everything wants control-alt-command-key no matter 
what.  =)

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

I think we inherited that from Sam's patches, since he's a trolltech guy 
I figured he knew what he was doing.  =)  If it's not necessary, it's no 
big deal to remove it.

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

oop, yeah, missed one when cleaning up all of my debug bits.

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

Should have been #ifdef'd.

> 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?)

I meant to turn it back.  Initially I added kdebug so I could do some 
quick debugging to figure out why argv stuff was messed up.  I saw there 
was only one printf type thing and thought it was silly to be mixing 
them, but in hindsight it's best to touch non-mac-specific stuff as 
little as possible, so I'll put it back.

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

None of the kgrantpty code works properly on OSX and I haven't had the 
opportunity to fix it correctly yet, so I just made it return for now, 
otherwise konsole dies since it's unable to chown the fd (dev is a 
dynamically generated directory on OSX and doesn't take kindly to that 
kind of thing, so kgrantpty in general isn't doing much good on OSX)

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

Yeah, it should.  Personally, I'm not really understanding why there's 
15 different places that things implement their own exec processing in 
the first place.  Why aren't they using kprocess, it seems like that's 
what it's for...?

I'd rather not have the code at all, but we need argv[0] to be the full 
path for the display server to be able to send events to the app.  Seems 
to be a side-effect of either how Quartz works, or how Qt tracks it's 
updates to Quartz.

> 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 :)

No, I think you were pretty much spot on.  Our changes are clearly still 
in the "hackish" stage.  There's a lot of stuff that needs to be done.

For one thing, anything that's using kstartupinfo is getting #ifdef'd 
out anywhere it's used, when it really makes more sense to stub (or 
reimplement) kstartupinfo; not sure how much it matters on non-x11 
platforms.

There's lots of other ugliness, our first goal was to just get things 
working at all.

-- 
Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/
gpg: 6401 D02A A35F 55E9 D7DD  71C5 52EF A366 D3F6 65FE
"Emacs is a nice operating system, but I prefer UNIX."
   -- Tom Christiansen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 253 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040101/4f607d50/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE-Darwin mailing list
KDE-Darwin at opendarwin.org
http://www.opendarwin.org/mailman/listinfo/kde-darwin