Tweaked qt ebuild [OBSOLETE]

Message

roderick · Post by **roderick** » Sun Feb 25, 2007 6:57 pm

I need to get in touch with Nxsty to see what he did to build the qt-copy patches as we need a new snapshot against 3.3.8 rather than try to use the 3.3.6 one. As well, if Nxsty is going to do that, then to host the file as well.

If/when I get this figured out, I'll post back and update the Changelog for the ebuild as well.

Cheers,

Rod.

kEiNsTeiN · Post by **kEiNsTeiN** » Thu Mar 01, 2007 12:34 am

hi!

Is the following a good idea?:

I had qt-3.3.8 installed. Then I downloaded the overlay on page 1. Now I will emerge qt-3.3.6-r4 with "risky" useflag (which will unmerge the already installed, _newer_ version). And I do that because it makes everything faster.... right?

Or is the portage 3.3.8 already equipped with that kdehiddenvisibility stuff? I dont even know what it does, but aparently it makes stuff fast.... So, what to do if you have no idea what you're doing? I also am using the Xeffects overlay, is there another weird ebuild with that risky useflag?

So basically: which ebuild best to use for visibility-support (whatever it is)??????

thanks

roderick · Post by **roderick** » Thu Mar 01, 2007 2:54 am

kEiNsTeiN wrote:hi!

Is the following a good idea?:

I had qt-3.3.8 installed. Then I downloaded the overlay on page 1. Now I will emerge qt-3.3.6-r4 with "risky" useflag (which will unmerge the already installed, _newer_ version). And I do that because it makes everything faster.... right?

Or is the portage 3.3.8 already equipped with that kdehiddenvisibility stuff? I dont even know what it does, but aparently it makes stuff fast.... So, what to do if you have no idea what you're doing? I also am using the Xeffects overlay, is there another weird ebuild with that risky useflag?

So basically: which ebuild best to use for visibility-support (whatever it is)??????

thanks

Don't use the downloaded tarball. If anything, install qt 3.3.8 from xeffects overlay. The tarball at the beginning of this thread is OOOOOLLLLLDDDDD (i.e. do not use it). You should not use the risky flag (unless you know what you are doing). Kdehiddenvisibility support is enabled in portage ebuild and in xeffects.

roderick · Post by **roderick** » Thu Mar 01, 2007 7:32 pm

The xeffects overlay contains the former pertty project and this tweaked qt project, along with the latest Xgl and beryl projects.

Details can be found at the xeffects wiki and/or forums.

Please direct any questions or issues to the xeffects forums and not here. There is also a bug tracker, for which you should submit bugs, rather than via Gentoo's bugzilla, as they cannot and will not support errors from overlay builds. Alternatively, you can try and reach one of the users or overlay mazintainers/developers via IRC on #gentoo-xeffects.

Regards,

Rod.

PS: Nxsty (or Mod) can lock this thread if you wish.

Hum · Post by **Hum** » Thu Mar 01, 2007 8:02 pm

I really hope this works for everyone.. I've tested the patch but i never did a build since I don't have a gentoo machine for the time being. http://www.cs.dal.ca/~seto/qt-copy-20070301.patch
http://www.boinc.ch/~gseto/qt-copy-20070301.patch

Hum · Post by **Hum** » Thu Mar 01, 2007 8:06 pm

roderick wrote:I need to get in touch with Nxsty to see what he did to build the qt-copy patches as we need a new snapshot against 3.3.8 rather than try to use the 3.3.6 one. As well, if Nxsty is going to do that, then to host the file as well.

If/when I get this figured out, I'll post back and update the Changelog for the ebuild as well.

Cheers,

Rod.

What I did was checked out qt-copy from svn and did a diff with qt-x11-free-3.3.8

roderick · Post by **roderick** » Thu Mar 01, 2007 9:27 pm

It's already done and added to xeffects. See post from earlier today. The xeffects overlay has this qt-copy patch and tested fine earlier.

Thanks,

Rod.

PS: check out the xeffects overlay and forum posts as indicated above.

Cheers.

IvanMajhen · Post by **IvanMajhen** » Fri Mar 02, 2007 7:22 pm

I already have compiled qt 3.3.6 from overlay and kdelibs with perrty and risky. If i want to update to qt 3.3.8, do i need to recompile kde?
What is new in qt-3.3.8? Is it faster?

roderick · Post by **roderick** » Fri Mar 02, 2007 8:25 pm

IvanMajhen wrote:I already have compiled qt 3.3.6 from overlay and kdelibs with perrty and risky. If i want to update to qt 3.3.8, do i need to recompile kde?
What is new in qt-3.3.8? Is it faster?

According to the portage Changelog, this is a version bump, which usually means bug fixes. Not sure if any new features were introduced.

However, having said that, the Qt 3.3.6 from the xeffects overlay does not have the qt-copy pathset from KDE enabled, as the 3.3.8 one does. The qt-copy patch set is a collection of enhancements, fixes, and changes that the KDE team have implemented on top of the free qt code. Qt 3.3.6 in portage has a select few of these patches and consequently so did 3.3.6 in the overlay, but not the full sett due to conflicts.

I have made a qt-copy snapshot and applied to the 3.3.8 build to regain the original qt-copy patches as this thread was originally opened for.

So, faster? Not sure. You may see some improvement, as some of the KDE tweaks did involve repaint improvements on the toolars and canvas.

Try it... Remember to enable USE="qt-copy". You can disable and try qt 3.3.8 from overlay without qt-copy by disabling the flag.

no4b · Post by **no4b** » Fri Mar 02, 2007 8:39 pm

I'm using qt-3.3.8 with risky and qt-copy now. No problems here.

IvanMajhen · Post by **IvanMajhen** » Fri Mar 02, 2007 9:00 pm

Thanks for info. So if only bugs are fixed then i think that kde doesn't need to be recompiled. Already compiled qt with qt-copy (pertty and risky were set before). Everything works.
Offtopic maybe:
Does QT have some xp or OSX style in it? When compiling i see messages (didn't remeber corectly) like DQT_NO_XP_STYLE, AQUA... or something like that. Could they be enabled?

roderick · Post by **roderick** » Fri Mar 02, 2007 10:12 pm

IvanMajhen wrote:Thanks for info. So if only bugs are fixed then i think that kde doesn't need to be recompiled. Already compiled qt with qt-copy (pertty and risky were set before). Everything works.
Offtopic maybe:
Does QT have some xp or OSX style in it? When compiling i see messages (didn't remeber corectly) like DQT_NO_XP_STYLE, AQUA... or something like that. Could they be enabled?

For qt, you may need to recompile kdelibs and kdeartwork-styles, but that should be it. See the elog infor from the qt install (it's in the ebuild and appears when you install).

As for the other stuff, that is for the windows or embedded version, and most likely not the free qt which this one is. Looking though the source code, qwindowsxpstyle.h is not found, and that is what the define would include if available.

no4b wrote:I'm using qt-3.3.8 with risky and qt-copy now. No problems here.

Awesome, I remember trying the risky flag early on and had lot's of problems.

davidomundo · Post by **davidomundo** » Thu Mar 08, 2007 9:59 am

enabling the risky flag on qt-3.3.6-r5 seems to break the skim package and disables all i18 input methods. skim successfully compiles, but no qt based windows accept input from skim, and skim config crashes. I'm rebuilding qt without the risky flag to see if it really is the patch's fault. There's no option of upgrading to qt-3.3.8 because it does not yet support immqt-bc, which is the use flag you need to allow i18 input in the first place.

davidomundo · Post by **davidomundo** » Thu Mar 08, 2007 10:27 am

I just recompiled qt-3.3.6-r5 with "-risky" and now skim is working.
So I guess the patch actually does break some packages.

lefsha · Post by **lefsha** » Thu Mar 08, 2007 6:43 pm

exactly!

but it is what risky stands for!

So what else you have expected?

Tweaked qt ebuild [OBSOLETE]

risky seems to break skim on qt-3.3.6-r5