qt-copy/patches

[Lubos Lunak]

 Hello,

 in case you haven't noticed yet, I've added a new directory patches/ to 
qt-copy. Even though it at first my look only as if I'm upset by the fact 
that most of these patches hang in qt-bugs@ for months, I actually see good 
reasons for having patches in qt-copy (also, this is not only my idea - when 
I mentioned creating patches dir for qt-copy, several people seemed quite 
happy with the idea, and I'm quite sure there won't be only my patches):

- First of all, those 'patch applied and sent to TT' commits get lost with 
next qt-copy update, if the patch didn't make it yet into official Qt. 
Keeping changes in qt-copy also as patches will make reapplying them easier.
- Keeping changes in qt-copy as patches should also make it easier to see how 
it differs from official Qt, and since some packagers use qt-copy for 
building their Qt packages, they can see what the differences are, and can 
pick ones they like.
- There is usually a bunch of patches handing in qt-bugs@ queue that improve 
some part of Qt noticeable, yet it can be months before somebody else then 
the patch author will be using the patch. To mention some of my patches, 
there are e.g. QPixmap<->QImage optimizations that make noticeably faster 
large images handling, there's a DND optimization that makes DND feel much 
faster, or there's a patch that makes the menubar applet obey Fitts' Law.
- Even though the patches should be very well tested, one can never test 
something too much. If TT hesitate to apply a patch, let's test it for them.
- blah blah blah
<flame>
- oh, and yes, I'm upset by the fact that some of my patches hang in qt-bugs@ 
for months. While I can understand that TT can't fullfil my every wish even 
if it includes a patch, just like the same happens with bugs.kde.org etc. 
(hate mails requesting KHotKeys2 finally being finished are welcome), that 
doesn't change anything on the fact that I don't like it, and having the 
patches in qt-copy will also have the additional benefit of making me less 
upset.
</flame>

 Now, the intention is not to fork Qt or anything like that. I've still kept 
my sanity ... hopefully ;). The patches in qt-copy/patches/ shouldn't make 
qt-copy incompatible with official Qt. There should be fixes, optimizations, 
and similar stuff.

 However, I've also created directory qt-copy/patches/notsafe, which should be 
for patches for which the above doesn't apply, for various reasons, the most 
common one being TT's extreme resistance to adding even the simplest new API 
to a stable release. Such patches should never be applied to qt-copy, and no 
code in CVS should rely on it. The patch of mine that's currently there quite 
likely won't make it in time for Qt-3.2, and if it will be so, KWin in KDE3.2 
will have a configure check and one of its best new features will be enabled 
only with patched Qt :(.

 If you add new patches, please:
- include the qt-bugs@ issue number
- explain what it does (pasting the qt-bugs@ mail will do ;) )
- keep the numbering, so that people know in which order to apply the patches, 
in case they depend on each other
- don't add crap

 Comments, flames, suggestions, requests demanding my head?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/