qt4-mac vs. qt4-x11

[Michael Dickens]

On Oct 23, 2010, at 3:43 PM, Ryan Schmidt wrote:
> On Oct 23, 2010, at 11:36, Marko Käning wrote:
>
>> just learnt that your port is aqua based and not using x11. :)
>>
>> I understand that this is some native port for KDE. I guess it could offer more performance or better integration into the window manager. Where can I read more about this project? Cool that it doesn't conflict with qt4-x11! :)
>>
>> Just trying my luck compiling the X11 version...
>>
>> Wondering whether I can replace qt4-mac in kdelibs4 by qt4-x11…
>
> qt4-x11 is a vastly outdated port, hasn't been touched in ages. Michael asked recently if anybody really needed it and I don't think anybody responded in the affirmative. I believe the plan is for qt4-mac to have an x11 variant (I see it currently does) and for qt4-x11 to be deleted.

Yes, what Ryan wrote is all correct.  Right now, the +x11 variant in qt4-mac won't work; I'm about 1/2 way through figuring out how to make qt4 work with MacPorts' X11 -- mostly tweaking QMake files to get the correct mix of "darwin-g++" and "x11", while removing certain "mac" parts (e.g., qmake itself requires MAC parts, but the GUI section must not since it's to be just X11).  I'm pretty sure the end-result will work for both +quartz and +x11, using the same patches -- but I'll test that out once I get there.  My hope is that one can have both +x11 and +quartz available, and swap between them to see how a given application works under those different conditions.  Probably a dream, but it's worth a try.

Adding that on my queue with a qt3 work-over as well as updating octave-devel to hopefully fix some bugs, and whatever else comes up w/r.t. the qt4-mac update.  I'm right now working on how to include the new qt4 portgroup inside a variant such that its "set" variables are available.  Hopefully fix that by the end of today ... never a dull moment! - MLD