unsubscribe
I wish to unsubscribe from [EMAIL PROTECTED]. I have already sent several mails to the above mail with subject unsubscribe. But I am still receiving the posts of this mailing-list. Can anybody tell me how to unsuscribe ? Thank in advance for your answer.
Re: unsubscribe
* MALHERBE HUGUES ([EMAIL PROTECTED]) wrote: > I wish to unsubscribe from [EMAIL PROTECTED] > I have already sent several mails to the above mail with subject unsubscribe. > But I am still receiving the posts of this mailing-list. > Can anybody tell me how to unsuscribe ? > Thank in advance for your answer. [EMAIL PROTECTED] you sent the email to the wrong address. Also, next time, take a look at the full email headers, they often have info on how to unsubscribe from lists. -- .''`. Carl B. Constantine : :' : [EMAIL PROTECTED] `. `'GnuPG: 135F FC30 7A02 B0EB 61DB 34E3 3AF1 DC6C 9F7A 3FF8 `- Debian GNU/Linux -- The power of freedom "Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world." ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trouble with delete-event
On Tue, Sep 02, 2003 at 05:52:10PM -0400, Owen Taylor wrote: > > I found the problem. It was due to the fact that when you click on the > > close button, the window isn't destroyed, but is put below the other > > windows. > > Yes, this is an (IMO) annoying misfeature of metacity. > > I think the intent is to get the window out of your way faster, but the > practical effect is increased confusion for even sophisticated users; > even when you don't lose windows, more stuff is moving around so it > makes the desktop feel less stable.) The intent was that if you close an unfocused window, it doesn't temporarily get focus just before it closes, I think. Well, that explains the window not getting raised anyway. I'm not sure why it gets lowered. May be in bugzilla somewhere. Havoc ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Trouble with delete-event
On Wed, Sep 03, 2003 at 05:33:44PM -0400, Havoc Pennington wrote: > On Tue, Sep 02, 2003 at 05:52:10PM -0400, Owen Taylor wrote: > > > I found the problem. It was due to the fact that when you click on the > > > close button, the window isn't destroyed, but is put below the other > > > windows. > > > > Yes, this is an (IMO) annoying misfeature of metacity. > > > > I think the intent is to get the window out of your way faster, but the > > practical effect is increased confusion for even sophisticated users; > > even when you don't lose windows, more stuff is moving around so it > > makes the desktop feel less stable.) > > The intent was that if you close an unfocused window, it doesn't > temporarily get focus just before it closes, I think. Well, that > explains the window not getting raised anyway. I'm not sure why it > gets lowered. May be in bugzilla somewhere. This sounds very similar to http://bugzilla.gnome.org/show_bug.cgi?id=115846 -Scott ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
On Tue, 02 Sep 2003 17:43:20 -0400 Owen Taylor <[EMAIL PROTECTED]> wrote: > I'd suggest looking at: > > http://bugzilla.gnome.org/show_bug.cgi?id=90082 > > instead. The problem is not > > "widgets should get all keystrokes before accelerator processing" > > But: > > "Input methods should get keystrokes before accelerator processing" > > The first would be a way of solving the second, but not the only > way. I thought the first is good way of solving second, but now I've understood first is not good way. because it's not compatible with the XEMBED spec. In addition, my patch at 111438 does not solve all of the second problem. So the patch is not good at all, I think. > > To solve this problem, once inputing starts, input method should > > steal all inputs from the keyboard until inputing ends, I think. (I > > haven't finished reading XEMBED Spec and haven't understood proper > > behavior of Client/Embedder, so I cannot say how we should do to > > solve the problem.) > > Yes, handling XEMBED is a major problem here. You are saying at Bug 90082, "Note that any method involve intercepting key events on the toplevel will not work in the context of embedding, as done with Bonobo". I interpreted this as follows, If client side widget connect signal to the toplevel, it will not work properly, because client has no toplevel or client toplevel is not real toplevel. (I don't know which is correct, but I think intercepting key events will not work in either.) My interpretation is right? Is there still any other problem? Intercepting key events on the toplevel will not work properly, so we have to find a new solution to solve this problem, and I propose a new solution. 1. add active (this means while inputing) im context variable to each toplevel window 2. while active im context exists, keystroke is passed to the im context first. Do you think this good or not good? Such change is easy? Regards, TOKUNAGA Hiroyuki ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: XIM key interpretation fix for 2.2.x?
> > 1. add active (this means while inputing) im context variable to >each toplevel window I'm not sure of all the details so I do apologize if I mis-assume something. I just wanted to make sure, if this happens, then what will be the case when say one activates an IM, but input focus go's off of a text input widget.. will keypresses still be passed to the IM? >From a application behaviour point of view (as opposed to the code's point of view) I think we want the im to steal events only when the focus appears to be on a text inputting widget and when the IM is active. I'm not sure if thats what you meant, or whether your proposed solution produces this effect. I only wish to confirm. Ken ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
