KDE + Qt/Mac -- how to handle it?
ranger at befunk.com
Thu Jan 1 15:59:16 GMT 2004
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.... =)
> 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
> 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
> Why did you add !key.isNull() checks in the X11 specific part of
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
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 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
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
Size: 253 bytes
Desc: not available
-------------- next part --------------
KDE-Darwin mailing list
KDE-Darwin at opendarwin.org
More information about the kde-core-devel