Mailinglist Archive: opensuse-gnome (174 mails)

< Previous Next >
Re: [opensuse-gnome] libwnck patches
  • From: JP Rosevear <jpr@xxxxxxxxxx>
  • Date: Thu, 06 Mar 2008 00:22:59 +0000
  • Message-id: <1204762979.3289.135.camel@xxxxxxxxxxxxxxxxxxxxx>

On Thu, 2008-03-06 at 00:43 +0100, Vincent Untz wrote:

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@xxxxxxx

- 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:

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 Rosevear <jpr@xxxxxxxxxx>
Novell, Inc.

To unsubscribe, e-mail: opensuse-gnome+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-gnome+help@xxxxxxxxxxxx

< Previous Next >