On Thu, 2008-03-06 at 00:43 +0100, Vincent Untz wrote:
Hi,
So, I wanted to play a bit with the patch upstreaming project, and I chose libwnck to start. I don't want to break things or something else, so I'm sending the results here, to get some comments/help.
There are four patches:
- libwnck-2.12.2-window-move-1.patch This is... crazy. This adds a new API: wnck_window_move(), which is available as wnck_window_set_geometry()... I'll assume this function was not available when the patch got created. Let's kill the patch, but we need to check if another package depends on the new API.
The 2.12.2 indicates when it was created. I presume it comes from this changelog entry: ------------------------------------------------------------------- Sat Jan 7 01:36:04 CET 2006 - dreveman@suse.de - Add window movement patch So can probably mail David to find out whats up - I presume compiz needed this for something, there were a number of bugs in SLED 10 with libwnck and compiz.
- libwnck-border_width-fix-2.patch The patch is simply wrong. It tries to add the border width to the window in some ways. Except that we're already handling them in another way. Or I'm missing something... Technically, it might help improve situation a bit for WMs that do not respect the EWMH, but libwnck is not supposed to work really well with those WM... Original bug: https://bugzilla.novell.com/show_bug.cgi?id=178222
This could indeed be dead now with the new gtk-window-decorator (instead of gnome-window decorator). David and cyberorg may know for sure.
- libwnck-opacity-2.patch This adds some new API to set the opacity and add a menu item in the window menu (which is used in the window list and in the compiz decorator) to set the opacity. First part might go upstream once the hint to set opacity is standardized and second part will not go upstream, and I must say I think it's wrong to add this item. I propose to simply remove the patch. But we might need to check if another package uses the new API. Any hint on how to do so?
Well, its not being applied now, but this was one of the first "nifty" compiz features in sled, its a good idea to keep SLED features like this so we don't regress, although I agree we should get to fixing it the right way. I doubt anything other than the two packages you mention are using it since everything is still building, including compiz, so this probably needs checking with David and cyberorg as well.
- libwnck-realistic-layout.patch Has been fixed upstream for quite some time now.
No problem dropping, I'd reference the upstream bug # in the changelog so it can be checked later if need be.
So, how to continue from here? :-)
The goal generally for each patch is to drop it if its obsolete by upstream changes or something else and we can explicitly reference bugs or upstream changelogs or something to give assurance this is correct. So in this case I would say you have the info for the fourth patch and you need to track down the origin of the first three. I know I dropped a few xgl patches a few months ago when tagging after talking to David (in gnome-session i think), so its quite likely we can drop these. If dropping any of the patches would regress SLED functionality, we want to keep it at least for now probably (as sucky as the patch may be - but indicate that in the patch comment and file an upstream bug if applicable to get it fixed the Right Way). -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org