qt-copy/patches

[Matt Rogers]

On Monday 30 June 2003 12:12 pm, Lubos Lunak wrote:
>  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?

This seems like a great idea! A perfect example of a patch that would be 
appropriate to be placed here (only if it hasn't already been included in QT) 
would the patch that Gentoo has that keeps QT Designer from crashing when 
loading the KDE widget set. 

Matt