From julian.adams@gmx.net Fri May 4 05:45:10 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by mail.gnome.org (Postfix) with SMTP id 343B92CEBC for ; Fri, 4 May 2001 05:43:11 -0400 (EDT) Received: (qmail 31843 invoked by uid 0); 4 May 2001 09:43:09 -0000 Received: from unknown (HELO JADAMS.gmx.net) (212.74.3.86) by mail.gmx.net (mail09) with SMTP; 4 May 2001 09:43:09 -0000 Message-Id: <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> X-Sender: zaftig.freeserve.co.uk@pop.freeserve.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 04 May 2001 10:46:34 +0100 To: Owen Taylor From: julian adams Subject: Re: Publish revised spec ? Cc: wm-spec-list@gnome.org In-Reply-To: References: <01042216381500.00718@babybel.at_home> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification I'll write up the changes over the next week, and then we can put it out. julian At 19:55 23/04/2001, Owen Taylor wrote: >Julian Adams writes: > > > I've commited a minor revision to the spec in CVS, clarifying=20 > _NET_SUPPORTED as > > discussed before. (diff below) > > > > I think this version of the spec (mainly David Wheeler's corrections)=20 > should > > get put out as a release as there are essential clarifications and=20 > corrections > > (e.g. the icon format). > >For people's reference, I've appended the diff -u betwen 1.0 and the >current version, with annotations to point what ones are spelling/etc. >and what ones are significant. > >The Changes section at the end needs to be updated to reflect the >3 significant changes. > >I think putting out a new revision at this point should be fine, >assuming everyone agrees with these changes. > >Regards, > Owen > > > diff -u -r1.9 -r1.11 > --- wm-spec.sgml 2000/11/22 21:40:56 1.9 > +++ wm-spec.sgml 2001/04/22 10:14:49 1.11 > @@ -1,22 +1,36 @@ > - + ]> >
> - > + > + > + > + X Desktop Group > + > + > Extended Window Manager Hints > -5 November 2000 > - > +10 March 2001 > + > >Fix doctype, add author info, update data. > > > Introduction > > Version > > -This spec is version 1.0. > +This is version 1.1 of the Extended Window Manager Hints (EWMH) spec, > +updated 10 March 2001. > >Update version > > > > What is this spec? > > -This spec defines interactions between window managers, applications=20 > and the utilities that form part of a desktop environment. It builds on= =20 > the ICCCM [2], which defines wm/client interactions at a lower level. It= =20 > was born out of a need to replace the original Gnome WM specification,=20 > although this specification has been designed to be independent of any=20 > one desktop environment. > +This spec defines interactions between window managers, applications, > +and the utilities that form part of a desktop environment. It builds > +on the ICCCM [2], which defines WM (window manager) interactions at a > +lower level. The ICCCM does not provide ways to implement many > +features that modern desktop users expect. The GNOME and KDE desktop > +projects originally developed their own extensions to the ICCCM to > +support these features; this spec replaces those custom extensions > +with a standardized set of ICCCM additions that any desktop > +environment can adopt. > >Change wording to be more inclusive, and to reflect the joint nature >of the specification. > > > > > @@ -82,7 +96,7 @@ > > > Modality > -The Window Manager_TRANSIENT_FOR hint of the ICCCM allows=20 > clients to specify that a > +The Window Manager _TRANSIENT_FOR hint of the ICCCM allows=20 > clients to specify that a > >Fix missing space. > > toplevel window may be closed before the client finishes. A typical=20 > example > of a transient window is a dialog. Some dialogs can be open for a=20 > long time, > while the user continues to work in the main window. Other dialogs=20 > have to be > @@ -183,7 +197,7 @@ > > > Animated iconification > -Some Window Managers display some form of animation when=20 > (de-)iconfying a window. > +Some Window Managers display some form of animation when=20 > (de-)iconifying a window. > >Spelling fix. > > This may be a line drawing connecting the corners of the window with > the corners of the icon or the window may be opaquely moved and resized > on some trajectory joining the window location and the icon=20 > location. > @@ -249,8 +263,10 @@ > ]]> > > This property MUST be set by the Window Manager to indicate which hints= it > -supports. This assumes that backwards incompatible changes will not=20 > be made > -to the hints (without being renamed). > +supports. For example: considering _NET_WM_STATE > +both this atom and all supported states e.g. _NET_WM_STATE_MODAL, > +_NET_WM_STATE_STICKY, would be listed. This assumes that backwards > +incompatible changes will not be made to the hints (without being=20 > renamed). > >Change to include ALL atoms, not just the property names. > > > _NET_CLIENT_LIST > @@ -286,7 +302,7 @@ > The Window Manager is free to honor or reject this request. If request= =20 > is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of=20 > desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of=20 > desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and=20 > _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES=20 > property MAY remain unchanged. > > > -If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out= =20 > of the new range of of available desktops, then this MUST must be set to= =20 > the last available desktop from the new set. If number of desktops is=20 > shrinking then clients that are still present on desktops, that are out=20 > of the new range, MUST be moved to the very last desktop from the new=20 > set. For these _NET_WM_DESKTOP MUST be updated. > +If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out= =20 > of the new range of available desktops, then this MUST be set to the last= =20 > available desktop from the new set. If number of desktops is shrinking=20 > then clients that are still present on desktops, that are out of the new= =20 > range, MUST be moved to the very last desktop from the new set. For these= =20 > _NET_WM_DESKTOP MUST be updated. > >Remove excess 'of', 'must'. > > > > > @@ -577,7 +593,7 @@ > _NET_WM_WINDOW_TYPE, ATOM[]/32 > ]]> > > -This MUST be set by the Client before mapping, to a list of atoms=20 > indicating > +This SHOULD be set by the Client before mapping, to a list of atoms=20 > indicating > the functional type of the window. This property SHOULD be used by=20 > the window > manager in determining the decoration, stacking position and other=20 > behaviour > of the window. The Client SHOULD specify window types in order of=20 > preference > >Change MUST to SHOULD. > > @@ -757,7 +773,7 @@ > > > This is an array of 32bit packed CARDINAL ARGB with high byte being A,= low > -byte being B. First two bytes are width, height. Data is in rows,=20 > left to > +byte being B. First two cardinals are width, height. Data is in=20 > rows, left to > right and top to bottom. > > > >Fix problem where 'bytes' should have been 'cardinals' > > @@ -1062,10 +1078,10 @@ > > > > -[1] ICCCM Version 2.0, =A74.1.2.3 and =A74.1.5 > +[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 > > > -[2] ICCCM Version 2.0, =A74.2.3 > +[2] ICCCM Version 2.0, §4.2.3 > >Replace iso-8559-1 with entitities. From hp@redhat.com Fri May 4 09:27:31 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 6B5B12DBD3 for ; Fri, 4 May 2001 09:27:31 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44DTaw07396; Fri, 4 May 2001 09:29:36 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: julian adams Cc: Owen Taylor , wm-spec-list@gnome.org Subject: Re: Publish revised spec ? References: <01042216381500.00718@babybel.at_home> <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> From: Havoc Pennington Date: 04 May 2001 09:29:36 -0400 In-Reply-To: julian adams's message of "Fri, 04 May 2001 10:46:34 +0100" Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification julian adams writes: > I'll write up the changes over the next week, and then we can put it out. > I think I already dumped it on the web page a week or so ago... hope this doesn't upset anyone. Maybe we can do an announce, if the changes are interesting enough. Havoc From hp@redhat.com Fri May 4 12:52:19 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 069812E957 for ; Fri, 4 May 2001 12:52:16 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44GsQd27078; Fri, 4 May 2001 12:54:26 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: wm-spec-list@gnome.org Subject: "What's this" From: Havoc Pennington Date: 04 May 2001 12:54:25 -0400 Message-ID: Lines: 11 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Hi, Has anyone implemented or considered implementing the Windows feature where the frame has a ? on it, and you click that to enter "What's this" mode and can then get help on stuff in the window? (Or is it a global mode and you can get help on anything onscreen?) Seems like we could have a simple protocol enabling this. Havoc From tibirna@kde.org Fri May 4 13:12:23 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by mail.gnome.org (Postfix) with ESMTP id C51302DFB4 for ; Fri, 4 May 2001 13:11:29 -0400 (EDT) Received: from there ([64.229.234.15]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> for ; Fri, 4 May 2001 13:11:29 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Cristian Tibirna Organization: KDE To: wm-spec-list@gnome.org Subject: Re: "What's this" Date: Fri, 4 May 2001 13:12:02 -0400 X-Mailer: KMail [version 1.2.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Friday 04 May 2001 12:54, you wrote: > Hi, > > Has anyone implemented or considered implementing the Windows feature > where the frame has a ? on it, and you click that to enter "What's > this" mode and can then get help on stuff in the window? (Or is it a > global mode and you can get help on anything onscreen?) > KDE has it all over the place. You actually get help only for the widgets for which you write "what's this" information explicitely, in KDE. But I believe this could be implemented otherwise in other places. > Seems like we could have a simple protocol enabling this. Hmm? Isn't this in the new NET spec already? -- Cristian Tibirna .. tibirna@sympatico.ca PhD Student .. ctibirna@giref.ulaval.ca .. www.giref.ulaval.ca/~ctibirna KDE contact - Canada .. tibirna@kde.org .. www.kde.org From sopwith@redhat.com Fri May 4 15:14:08 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 73E892C934 for ; Fri, 4 May 2001 15:14:08 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f44JE8S03930 for ; Fri, 4 May 2001 15:14:08 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Fri, 4 May 2001 15:14:07 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Subject: Re: "What's this" In-Reply-To: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Fri, 4 May 2001, Cristian Tibirna wrote: > > Has anyone implemented or considered implementing the Windows feature > > where the frame has a ? on it, and you click that to enter "What's > > this" mode and can then get help on stuff in the window? (Or is it a > > global mode and you can get help on anything onscreen?) > > KDE has it all over the place. You actually get help only for the widgets for > which you write "what's this" information explicitely, in KDE. But I believe > this could be implemented otherwise in other places. > > > Seems like we could have a simple protocol enabling this. > > Hmm? > > Isn't this in the new NET spec already? KDE just uses the Qt hack that does it in one process only. Doing that is easy and irrelevant to this list. A reasonable requirement would be for a "what's this" solution to work inter-application, which would mean coming up with an X protocol to do it. I started looking at this for gnome-libs once - the way I was thinking of doing it was having cursor feedback similar to DnD to point out areas that help can be given for, plus a way to tell the clicked-on area to show its help, once it is clicked. -- Elliot These three lines are for sale at the rate of $50/month. From hp@redhat.com Fri May 4 18:28:30 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 11E322BBE4 for ; Fri, 4 May 2001 18:28:29 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44MTgq03942; Fri, 4 May 2001 18:29:42 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Cristian Tibirna Cc: wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> From: Havoc Pennington Date: 04 May 2001 18:29:42 -0400 In-Reply-To: Cristian Tibirna's message of "Fri, 4 May 2001 13:12:02 -0400" Message-ID: Lines: 13 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Cristian Tibirna writes: > Isn't this in the new NET spec already? > I don't believe so, as Elliot says. I'm thinking of a protocol to do it; either a simple one so you could click ? on a window and get help for stuff inside that window (relatively easy) or a more complex thing so you can get help anywhere on the screen. I'm not sure which one Windows has, actually. Havoc From hp@redhat.com Fri May 4 19:56:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 4110A2BB87 for ; Fri, 4 May 2001 19:56:13 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44NvbY14667; Fri, 4 May 2001 19:57:37 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Damon McGraw Cc: Cristian Tibirna , wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> <20010504194831.A15323@watchland.org> From: Havoc Pennington Date: 04 May 2001 19:57:37 -0400 In-Reply-To: Damon McGraw's message of "Fri, 4 May 2001 19:48:31 -0400" Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Damon McGraw writes: > > Having it available for the whole screen would be a plus (that way you > could get it for panel applets as well as full apps). But wouldn't it > make more sense if the button (or whatever) to activate it wasn't in a > app? Perhaps somewhere on the panel or something instead? > Seems likely that's not really an issue the protocol would need to address - there would be some way to say "enter whatsthis mode" and the window manager or panel or whatever could provide a button that did that. Havoc From l.lunak@sh.cvut.cz Sat May 5 05:11:16 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mail.gnome.org (Postfix) with ESMTP id AABCF2CDA1 for ; Sat, 5 May 2001 05:11:15 -0400 (EDT) Received: from stoupa.sh.cvut.cz (stoupa.sh.cvut.cz [147.32.127.196]) by service.sh.cvut.cz (8.9.3/SH) with ESMTP id LAA15174 for ; Sat, 5 May 2001 11:11:14 +0200 Received: from there (seli@seli.sh.cvut.cz [147.32.122.38]) by stoupa.sh.cvut.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id LAA01583 for ; Sat, 5 May 2001 11:11:14 +0200 Message-Id: <200105050911.LAA01583@stoupa.sh.cvut.cz> Content-Type: text/plain; charset="iso-8859-2" From: Lubos Lunak To: wm-spec-list@gnome.org Subject: Re: "What's this" Date: Sat, 5 May 2001 11:11:12 +0200 X-Mailer: KMail [version 1.2.1] References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Dne so 5. kv=ECten 2001 00:29 jste napsal(a): > Cristian Tibirna writes: > > Isn't this in the new NET spec already? > > I don't believe so, as Elliot says. > > I'm thinking of a protocol to do it; either a simple one so you could > click ? on a window and get help for stuff inside that window > (relatively easy) or a more complex thing so you can get help anywhere > on the screen. I'm not sure which one Windows has, actually. Win2k has 'what's this' only for the active window, the same way it's in= =20 KDE/Qt ( which is IMHO good enough ). > > Havoc > Lubos Lunak -- l.lunak@email.cz ; l.lunak@kde.org http://dforce.sh.cvut.cz/~seli From otaylor@redhat.com Sat May 5 10:30:14 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from fresnel.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 5F7C52E087 for ; Sat, 5 May 2001 10:30:14 -0400 (EDT) Received: by fresnel.labs.redhat.com (Postfix, from userid 2181) id DB90A241C6D; Sat, 5 May 2001 10:30:13 -0400 (EDT) To: wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> <200105050911.LAA01583@stoupa.sh.cvut.cz> From: Owen Taylor Date: 05 May 2001 10:30:13 -0400 In-Reply-To: Lubos Lunak's message of "Sat, 5 May 2001 11:11:12 +0200" Message-ID: Lines: 47 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Lubos Lunak writes: > Dne so 5. kv=ECten 2001 00:29 jste napsal(a): > > Cristian Tibirna writes: > > > Isn't this in the new NET spec already? > > > > I don't believe so, as Elliot says. > > > > I'm thinking of a protocol to do it; either a simple one so you could > > click ? on a window and get help for stuff inside that window > > (relatively easy) or a more complex thing so you can get help anywhere > > on the screen. I'm not sure which one Windows has, actually. >=20 > Win2k has 'what's this' only for the active window, the same way it's in= =20 > KDE/Qt ( which is IMHO good enough ). Considering that: - "What's this" needs to be activated at least from the window manager title bar. - "What's this" needs to work across embedded subwindows. I don't think you get any essential simplification in implementation from allowing it only in a single window. And I think it's easy to do better than Windows in this respect: - Provide "what's this" globally, and in particular on desktop features such as the taskbar and desktop icons. - Provide feedback during the "what's this operation". (Having to guess what has help, and then restart the operation is the thing I found most annoying trying out this feature in Windows.) (The simplest feedback is simply a yes/no indication as in DND.=20 This is easy to implement and easy to standardize. I suspect it's possible to do better than this, either by providing some visual clue as to what elements have help, or by displaying the help immediately on mouse-over; but I'm not sure that the extra complexity would be worth it.) Regards, Owen From M.Rogers@cs.ucl.ac.uk Sat May 5 11:34:23 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.gnome.org (Postfix) with SMTP id 415192E0AD for ; Sat, 5 May 2001 11:34:23 -0400 (EDT) Received: from moorgate.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 5 May 2001 16:34:19 +0100 To: wm-spec-list@gnome.org Subject: Re: "What's this" In-reply-to: Your message of "04 May 2001 19:57:37 EDT." Date: Sat, 05 May 2001 16:34:18 +0100 Message-ID: <892.989076858@cs.ucl.ac.uk> From: Michael ROGERS Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification >Seems likely that's not really an issue the protocol would need to >address - there would be some way to say "enter whatsthis mode" and >the window manager or panel or whatever could provide a button that >did that. How about this: When the help button is pressed, the help client (could be the WM or a panel applet) grabs the pointer and installs a ? cursor. When the user clicks on an item, the help client sends a client message to the clicked window and releases the pointer. Clients that don't understand the message will ignore it; clients that understand it can display help. This could be a top-level help window, or one of those popup explanations that Windows uses, which don't disappear until you click on something. (Grab the pointer and use redirect override on the tooltip window?) This mechanism could be tied into the existing KDE help system (Qt would detect the client messages and invoke the existing mechanism), so a panel applet or WM could trigger the context-sensitive help attached to KDE widgets. Michael From jg@pa.dec.com Sat May 5 22:05:16 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.gnome.org (Postfix) with ESMTP id 113442CA71 for ; Sat, 5 May 2001 22:05:16 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 44D031C81; Sat, 5 May 2001 21:05:15 -0500 (CDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E7DAFD37; Sat, 5 May 2001 21:05:14 -0500 (CDT) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 897AC42F; Sat, 5 May 2001 22:05:14 -0400 (EDT) Received: from src-mail.pa.dec.com (src-mail.pa.dec.com [16.4.16.35]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 00F6E5EA; Sat, 5 May 2001 22:05:13 -0400 (EDT) Received: by src-mail.pa.dec.com; id TAA09428; Sat, 5 May 2001 19:05:13 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Received: (from pachydrm@localhost) by pachyderm.pa.dec.com (8.11.1/8.11.1) id f4625DU497096; Sat, 5 May 2001 19:05:13 -0700 (PDT) Date: Sat, 5 May 2001 19:05:13 -0700 (PDT) Message-Id: <200105060205.f4625DU497096@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Elliot Lee Cc: wm-spec-list@gnome.org In-Reply-To: Subject: Re: "What's this" Mime-Version: 1.0 Content-Type: text/plain Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification All that is really needed is to decorate the widget windows with the class and instance data from the toolkit, and then one can have an external process do the display. We need that data for things like "Hands off X" to work, and doing it externally means that it can be done to almost any application, independent of the author, in a uniform fashion across toolkits. - Jim > Sender: wm-spec-list-admin@gnome.org > From: Elliot Lee > Date: Fri, 4 May 2001 15:14:07 -0400 (EDT) > To: > Subject: Re: "What's this" > ----- > On Fri, 4 May 2001, Cristian Tibirna wrote: > > > > Has anyone implemented or considered implementing the Windows feature > > > where the frame has a ? on it, and you click that to enter "What's > > > this" mode and can then get help on stuff in the window? (Or is it a > > > global mode and you can get help on anything onscreen?) > > > > KDE has it all over the place. You actually get help only for the widgets > for > > which you write "what's this" information explicitely, in KDE. But I believe > > this could be implemented otherwise in other places. > > > > > Seems like we could have a simple protocol enabling this. > > > > Hmm? > > > > Isn't this in the new NET spec already? > > KDE just uses the Qt hack that does it in one process only. Doing that is > easy and irrelevant to this list. A reasonable requirement would be for a > "what's this" solution to work inter-application, which would mean coming > up with an X protocol to do it. > > I started looking at this for gnome-libs once - the way I was thinking of > doing it was having cursor feedback similar to DnD to point out areas that > help can be given for, plus a way to tell the clicked-on area to show its > help, once it is clicked. > > -- Elliot > These three lines > are for sale > at the rate of $50/month. > > > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com From hp@redhat.com Sun May 6 01:28:10 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 33B1C2CE26 for ; Sun, 6 May 2001 01:28:10 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f465UFd15508; Sun, 6 May 2001 01:30:15 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: jg@pa.dec.com (Jim Gettys) Cc: Elliot Lee , wm-spec-list@gnome.org Subject: Re: "What's this" References: <200105060205.f4625DU497096@pachyderm.pa.dec.com> From: Havoc Pennington Date: 06 May 2001 01:30:15 -0400 In-Reply-To: jg@pa.dec.com's message of "Sat, 5 May 2001 19:05:13 -0700 (PDT)" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification jg@pa.dec.com (Jim Gettys) writes: > All that is really needed is to decorate the widget windows with > the class and instance data from the toolkit, and then one can > have an external process do the display. One problem with that is that we already have a bunch of widgets (or useful-to-communicate-with widget subportions such as sheet cells) that don't have an X window. > We need that data for things like "Hands off X" to work, > and doing it externally means that it can be done to almost any > application, independent of the author, in a uniform fashion > across toolkits. If "Hands off X" is speech recognition stuff, the general GTK plan here (for in-process) is the accessibility API Sun is contributing. Then there is some out-of-process protocol yet to be defined, and a GTK module would be loaded into apps which exported the data obtained from the accessibility API to an alternative/supplemental input/output mechanism living in another process. I think "what's this" is very simple; you just have some way of signaling that you're in "what's this" mode, toolkits highlight widgets with available help; and you send some sort of message to whatever window gets clicked on, and the toolkit pops up the help. App authors just call widget_set_whats_this() and the toolkit magically makes it work. Havoc From olivier.chapuis@free.fr Sun May 6 09:02:42 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by mail.gnome.org (Postfix) with ESMTP id A50FA2BE20 for ; Sun, 6 May 2001 09:02:41 -0400 (EDT) Received: from snoopy.parislyon (paris11-nas2-42-12.dial.proxad.net [212.27.42.12]) by postfix2-1.free.fr (Postfix) with ESMTP id 80AD7C0E9; Sun, 6 May 2001 15:02:39 +0200 (CEST) Received: from snoopy.parislyon (snoopy.parislyon [127.0.0.1]) by snoopy.parislyon (Postfix) with SMTP id B1020242ED; Sun, 6 May 2001 14:54:53 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Olivier Chapuis To: fvwm-announce@fvwm.org, wm-spec-list@gnome.org Subject: fvwm-ewmh-0.1 is released Date: Sun, 6 May 2001 14:54:52 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01050614545200.26369@snoopy.parislyon> Content-Transfer-Encoding: 8bit Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification I am glad to announce the first version of fvwm-ewmh. fvwm-ewmh is constituted by a module, FvwmNetHints, and a patch against the last FVWM beta version (a stable candidate): fvwm-2.3.32. With these FVWM can handle Extended Window Manager Hints from the freedesktop group. This allows, for example, to run FVWM with KDE version 2. This package is alpha, however, it works not so bad on my machine. I announce this release with the hope to get some feedback before releasing version 0.2 which will be released a few days after fvwm-2.4.0 (with no announce to this list). Home Page (Download, Installation, Running, FAQ): http://fvwm-ewmh.sourceforge.net/ Screen Shots: http://fvwm-ewmh.sourceforge.net/screenshots/ Regards, Olivier From Sasha_Vasko@osca.state.mo.us Mon May 7 12:16:56 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 26C0A2DBB2 for ; Mon, 7 May 2001 12:16:56 -0400 (EDT) Subject: Re: "What's this" To: wm-spec-list@gnome.org, Michael ROGERS From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 11:13:56 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 11:14:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > >Seems likely that's not really an issue the protocol would need to > >address - there would be some way to say "enter whatsthis mode" and > >the window manager or panel or whatever could provide a button that > >did that. > > How about this: > > When the help button is pressed, the help client (could be the WM or a > panel applet) grabs the pointer and installs a ? cursor. When the user > clicks on an item, the help client sends a client message to the clicked > window and releases the pointer. Clients that don't understand the > message will ignore it; clients that understand it can display help. Clients should not be bothered with displaying help, unless you want to bloat all of them with basically identical help rendering code. Much cleaner approach would be for single help app. It would query client about context of the mouse click ( basically send it message like: ) on which client should respond with meaningfull text data identifying what help should be displayed - something like . help app then goes and at all known to it locations for this particular information. In case client does not support/respond to thins protocol - then help app simply falls back to using res_name, res_class from client's hints, and goes looking for the man page for this client. X selections would be a good way to implement such a protocol. Compliant clients should acqure ownership of the selection on its top level window something like _NET_HELP. help app then sends them request, passing parameters along in its target property _NET_HELP_REQUEST, created on its own window. And client should respond to it, by placing click context description info into this target property. If client is not an owner of selection _NET_HELP or if it does not respond within reasonable timeout - help app goes on and displays help based on clients Class hints. Something along this lines. > This could be a top-level help window, or one of those popup > explanations that Windows uses, which don't disappear until you click on > something. (Grab the pointer and use redirect override on the tooltip > window?) > > This mechanism could be tied into the existing KDE help system (Qt would > detect the client messages and invoke the existing mechanism), so a > panel applet or WM could trigger the context-sensitive help attached to > KDE widgets. > > Michael > Regards Sasha Vasko From sopwith@redhat.com Mon May 7 12:37:02 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id D79E52CBBE for ; Mon, 7 May 2001 12:37:01 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Gav525322; Mon, 7 May 2001 12:36:57 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 12:36:57 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Jim Gettys Cc: Subject: Re: "What's this" In-Reply-To: <200105060205.f4625DU497096@pachyderm.pa.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Sat, 5 May 2001, Jim Gettys wrote: > All that is really needed is to decorate the widget windows with > the class and instance data from the toolkit, and then one can > have an external process do the display. This is not sufficient to meet the requirements I had in mind. The application whose help is being requested has to be asked to display the help, because it can display it in a manner that best fits the item in question. Also, this approach won't work for widgets without windows... (Not saying that that class/instance info does/doesn't need to be there, of course - if you want it there just file a gtk bug. :-) -- Elliot These three lines are for sale at the rate of $50/month. From sopwith@redhat.com Mon May 7 12:45:02 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 6E5322BAB1 for ; Mon, 7 May 2001 12:45:02 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Giua26941; Mon, 7 May 2001 12:44:56 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 12:44:56 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Cc: , Michael ROGERS Subject: Re: "What's this" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > Clients should not be bothered with displaying help, unless you want to > bloat all of them with basically identical help rendering code. Clients are the only pieces that know how to best display the help. If someone wants to implement the paperclip (whether you like it or not, that case needs to be possible), doing it in the client is the only sane way. If client wishes to use a standardized-help-display-mechanism to show the popup help, then it is entirely possible, but that's a separate problem to be solved - let's not complicate the problem further than it has to be. Right now the only thing to do is find out whether a client has help available for a widget (to provide cursor feedback) and ask the client to provide that help... So, I'm in rough agreement with Havoc on this one, -- Elliot These three lines are for sale at the rate of $50/month. From jg@pa.dec.com Mon May 7 13:20:11 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.gnome.org (Postfix) with ESMTP id 3B3E72BBE0 for ; Mon, 7 May 2001 13:20:11 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 83655CFF; Mon, 7 May 2001 12:20:10 -0500 (CDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4A9A3E18; Mon, 7 May 2001 12:20:10 -0500 (CDT) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id EB7F329B; Mon, 7 May 2001 10:20:09 -0700 (PDT) Received: from src-mail.pa.dec.com (src-mail.pa.dec.com [16.4.16.35]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id DCF0315A; Mon, 7 May 2001 10:20:09 -0700 (PDT) Received: by src-mail.pa.dec.com; id KAA17194; Mon, 7 May 2001 10:20:09 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Received: (from pachydrm@localhost) by pachyderm.pa.dec.com (8.11.1/8.11.1) id f47HK97280588; Mon, 7 May 2001 10:20:09 -0700 (PDT) Date: Mon, 7 May 2001 10:20:09 -0700 (PDT) Message-Id: <200105071720.f47HK97280588@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Elliot Lee Cc: Jim Gettys , wm-spec-list@gnome.org In-Reply-To: Subject: Re: "What's this" Mime-Version: 1.0 Content-Type: text/plain Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > From: Elliot Lee > Date: Mon, 7 May 2001 12:36:57 -0400 (EDT) > To: Jim Gettys > Cc: > Subject: Re: "What's this" > ----- > On Sat, 5 May 2001, Jim Gettys wrote: > > > All that is really needed is to decorate the widget windows with > > the class and instance data from the toolkit, and then one can > > have an external process do the display. > > This is not sufficient to meet the requirements I had in mind. The > application whose help is being requested has to be asked to display the > help, because it can display it in a manner that best fits the item in > question. Yes, but it would get 90%, and would allow for help on toolkits that don't do this at all. So how about this scheme, suitably modified to inform clients, so that they can provide help if need be to cover these cases. > > Also, this approach won't work for widgets without windows... > > (Not saying that that class/instance info does/doesn't need to be there, > of course - if you want it there just file a gtk bug. :-) OK, will do :-). Where is the bug reporting system? - Jim -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com From Sasha_Vasko@osca.state.mo.us Mon May 7 13:27:20 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 70E442BBE0 for ; Mon, 7 May 2001 13:27:20 -0400 (EDT) Subject: Re: "What's this" To: Elliot Lee Cc: From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 12:24:32 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 12:24:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > > > Clients should not be bothered with displaying help, unless you want to > > bloat all of them with basically identical help rendering code. > > Clients are the only pieces that know how to best display the help. If > someone wants to implement the paperclip (whether you like it or not, that > case needs to be possible), doing it in the client is the only sane way. While using proposed selection mechanism, it would be possible for client to respond with some special answer, indicating its desire to "Take over" help displaying. I would estimate, thou, that 95% of Unix/Linux/open source apps will not want to do that. It really is kinda stupid to write a man page, and then code huge piece of code into your application to display basically same information. I understand that this is different for BIG applications like Web Browsers/Word Processors, but we should not be thinking solely about those, and if there is a simple way of implementing generic algorithm, that automagically supports ALL unix applications, without changes required to most of those - we should go with it. Using huge library of man pages is a good thing (TM). > > If client wishes to use a standardized-help-display-mechanism to show the > popup help, then it is entirely possible, but that's a separate problem to > be solved - let's not complicate the problem further than it has to be. > Right now the only thing to do is find out whether a client has help > available for a widget (to provide cursor feedback) and ask the client to > provide that help... Selections mechanism is very simple to implement, and most of those BIG apps that needs it, should already have some selections management code, since things like clipboard are implemented this way. On the other hand standardizing some inferior ad-hoc solution is a nasty, way to go since it will provide a very limited solution (you don't have 2-way communications, so there is no way to find out if app has acknowledged request, and therefore you can't implement any fallback techniques ). And we'll need to live with it till the rest of our lives, and ppl will be pointing fingers, blaming us in very harsh words, and we'll be tearing our hair out, and there will not be a way back, etc. , etc., etc. Sooner or later some 2-way communications will have to be implemented, so why not do it right the first time. It's not like if we don't come up with something today - world collapses. > > So, I'm in rough agreement with Havoc on this one, > -- Elliot Regards Sasha Vasko From sopwith@redhat.com Mon May 7 13:37:20 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 081BF2E1BF for ; Mon, 7 May 2001 13:37:20 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Hb9404620; Mon, 7 May 2001 13:37:09 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 13:37:09 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Cc: Subject: Re: "What's this" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > I would estimate, thou, that 95% of Unix/Linux/open source apps will > not want to do that. It really is kinda stupid to write a man page Applications are free to share help system solutions, but they need to do it outside of this idea. Given that there are many other ways to use a help system beside "what's this" kind of help, and that the "what's this" help will need to be integrated into the other parts of the help system, it does not make sense to involve the help display part of things in this spec. This idea is not about specifying a common help system for displaying help, only about one particular method of requesting help that needs to be interoperable to benefit the user most. > On the other hand standardizing some inferior ad-hoc solution is a > nasty, way to go since it will provide a very limited solution (you > don't have 2-way communications, so there is no way to find out if app > has acknowledged request, and therefore you can't implement any > fallback techniques ). Cursor feedback was part of the requirements I gave. If an app doesn't participate in that, then you can do your fallback stuff. -- Elliot These three lines are for sale at the rate of $50/month. From hp@redhat.com Mon May 7 14:17:59 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 72FA92E249 for ; Mon, 7 May 2001 14:12:14 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f47IEAD22635; Mon, 7 May 2001 14:14:10 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org, Michael ROGERS Subject: Re: "What's this" References: From: Havoc Pennington Date: 07 May 2001 14:14:10 -0400 In-Reply-To: Sasha_Vasko@osca.state.mo.us's message of "Mon, 7 May 2001 11:13:56 -0500" Message-ID: Lines: 24 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Sasha_Vasko@osca.state.mo.us writes: > Clients should not be bothered with displaying help, unless you want to > bloat all of them with basically identical help rendering code. The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. There are two problems with the approach you mention: - people want something higher-level than text in the help, e.g. a simple HTML-like subset with links, etc. - help needs to work within a client even if no "help manager" app is running; i.e. the client needs a fallback implementation in any case, it can't rely on a desktop runtime environment being active. So you can't eliminate the toolkit code in any case. (And Qt already has this code, anyhow.) man pages certainly aren't the kind of help we're discussing here; what's this help is just a paragraph on the specific widget that's been clicked. Sort of longer tooltips, maybe with embedded links to the full documentation for the app. Havoc From Sasha_Vasko@osca.state.mo.us Mon May 7 15:26:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 7E7E72DB6D for ; Mon, 7 May 2001 15:26:13 -0400 (EDT) Subject: Re: "What's this" To: Havoc Pennington Cc: wm-spec-list@gnome.org, Michael ROGERS From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 14:23:25 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:23:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > Sasha_Vasko@osca.state.mo.us writes: > > Clients should not be bothered with displaying help, unless you want to > > bloat all of them with basically identical help rendering code. > > The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. > wait a sec. Are we disscussing "what's this" feature applicable only to toolkits ? If so then I retract all my proposals. I thought that you wanted to be able to get help not only on toolkit windows but universally on any object on the desktop. I don't think that any sane window manager is going to implement its own hyperlinked help browser - the best you can count on is popping up mozilla or term with man page/faqs displayed in it. What that brings you to is that user may get all kinds of help systems from different desktop objects - from GTK apps - one, from QT apps - another and completely different from something else, and nothing at all from most other things. All of those things will have different look and feel, which is not nice. If you really want to implement global help system, you have to think about signle app, that can display help for both GTK/Qt as well as the rest of the world. If all you need is internal toolkit help browser - then why bother with standard? I don't think it will make any sense at all for window manager to implement "What's it" button which will work only in GTK/QT, and will not work correctly even on its own interface elements. Besides do you actually see all the apps linked as dynamically only from now onwards? Cos if you link it statically - you do get bloat issue. > There are two problems with the approach you mention: > > - people want something higher-level than text in the help, > e.g. a simple HTML-like subset with links, etc. It's not difficult to implement help browser that would intelligently distinguish between help available in HTML, XML, man pages or any other format. And in fact man pages could be displayed as a hyperlinked text, and are very nice in that way. > > - help needs to work within a client even if no "help manager" app is > running; i.e. the client needs a fallback implementation in any > case, it can't rely on a desktop runtime environment being active. > So you can't eliminate the toolkit code in any case. (And Qt > already has this code, anyhow.) Well, if globally active help system is not running - then this entire disscussion is not applicable anyways - each client will have to rely upon itself entirely. The interesting implication is that you do not really need window manager involvement at all - you click on desktop icon/menu item-> that will launch help app -> help app grabs pointer and waits for a click -> then it traverses window tree in order to find out any parent window with wm hints set. etc. etc. etc. > man pages certainly aren't the kind of help we're discussing here; > what's this help is just a paragraph on the specific widget that's > been clicked. Sort of longer tooltips, maybe with embedded links to > the full documentation for the app. It still has to be a paragraph out of complete set of docs - and as such I do not see much difficulty in displaying particular topic out of HTML file, or even a man page for that matter. Anyways I just proposed the way it could be implemented using standard X approach. I don't seem to see any other alternative proposals, except for Michael Roger's one , which is basically the same as what I proposed, only with messages instead of selection( which is not good for 2-way communications). So what is this exactly we are arguing about ? What is your alternative? > > Havoc From Sasha_Vasko@osca.state.mo.us Mon May 7 15:33:11 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id D866D2CE3D for ; Mon, 7 May 2001 15:33:08 -0400 (EDT) Subject: Re: "What's this" To: , Elliot Lee Cc: From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 14:30:19 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:30:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > > > I would estimate, thou, that 95% of Unix/Linux/open source apps will > > not want to do that. It really is kinda stupid to write a man page > > Applications are free to share help system solutions, but they need to do > it outside of this idea. Given that there are many other ways to use a > help system beside "what's this" kind of help, and that the "what's this" > help will need to be integrated into the other parts of the help system, > it does not make sense to involve the help display part of things in this > spec. This idea is not about specifying a common help system for > displaying help, only about one particular method of requesting help that > needs to be interoperable to benefit the user most. X Selections is the most standrad and interoperable way to implement such things. It has been specifically designed for this purpose. > > On the other hand standardizing some inferior ad-hoc solution is a > > nasty, way to go since it will provide a very limited solution (you > > don't have 2-way communications, so there is no way to find out if app > > has acknowledged request, and therefore you can't implement any > > fallback techniques ). > > Cursor feedback was part of the requirements I gave. If an app doesn't > participate in that, then you can do your fallback stuff. What cursor feedback exactly are you talking about. Care to provide some definition ? Or did I miss something ? Besides any cursor manipulations by client apps are highly discouraged in X. > -- Elliot From hp@redhat.com Mon May 7 15:50:46 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 5EE832CB80 for ; Mon, 7 May 2001 15:50:46 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f47Jqf908069; Mon, 7 May 2001 15:52:41 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org, Michael ROGERS Subject: Re: "What's this" References: From: Havoc Pennington Date: 07 May 2001 15:52:41 -0400 In-Reply-To: Sasha_Vasko@osca.state.mo.us's message of "Mon, 7 May 2001 14:23:25 -0500" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Sasha_Vasko@osca.state.mo.us writes: > > So what is this exactly we are arguing about ? What is your alternative? > My original thought on this was just a spec for putting the ? button in the WM decoration. That is, the client would set a hint "I support what's this" and the WM would send a message if the user clicked the what's this button. But the actual help is just within the app. The more ambitious idea is that clicking what's this works for the entire desktop. This would require a protocol similar to drag-and-drop, which would normally be implemented in toolkits (since the only people who no longer use toolkits are people writing window managers, pretty much, and even the newer WMs use a toolkit whenever they want to display dialogs and such). This would work similar to drag-and-drop; a client would enter what's this mode (grab pointer, change cursor); somehow notify other clients that the mode was entered so they could highlight targets; as you moved the pointer around, it would change to indicate whether you were on a target; when you then clicked on a target, the target would receive some sort of message and reply back to the whatsthis-mode owner app that it should release the grab and leave the mode. There is a problem with inconsistency between toolkits, but this same problem exists for all aspects of toolkit look-and-feel, and it can be solved via theme coordination in the same way we'll solve e.g. button appearance. Havoc From raster@asterman.com Mon May 7 15:54:37 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from asterman.com (nat-hdqt.valinux.com [198.186.202.17]) by mail.gnome.org (Postfix) with ESMTP id 86D802CB80 for ; Mon, 7 May 2001 15:54:36 -0400 (EDT) Received: (from raster@localhost) by asterman.com (8.11.0/8.11.0) id f47Iuw925915; Mon, 7 May 2001 11:56:58 -0700 Message-Id: <200105071856.f47Iuw925915@asterman.com> Date: Mon, 7 May 2001 11:56:58 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: "What's this" To: Sasha_Vasko@osca.state.mo.us Cc: hp@redhat.com, wm-spec-list@gnome.org, M.Rogers@cs.ucl.ac.uk In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On 7 May, Sasha_Vasko@osca.state.mo.us scribbled: > > > Sasha_Vasko@osca.state.mo.us writes: > > > Clients should not be bothered with displaying help, unless you want to > > > bloat all of them with basically identical help rendering code. > > > > The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. > > > > wait a sec. Are we disscussing "what's this" feature applicable only to > toolkits ? If so then I retract all my proposals. > > I thought that you wanted to be able to get help not only on toolkit > windows > but universally on any object on the desktop. I don't think that any > sane window manager is going to implement its own hyperlinked help I'm not averse to doing it... :) it's kinda fun.. alreayd implimented one for E16 (dox) because i just wanst willing to wait 10 secons for netscape to pop up with help info in it for some simple help docs with inline diagrams and links within the doc... :) the wm doesnt have to actually impliment the cod if you dont want to.. it coudl pass it off to a helper app installed and exec it passing the info along... > browser - the best you can count on is popping up mozilla or term with > man page/faqs displayed in it. What that brings you to is that user may get > all kinds of help systems from different desktop objects - from GTK apps - > one, > from QT apps - another and completely different from something else, > and nothing at all from most other things. All of those things will > have different look and feel, which is not nice. If you really want to > implement global help system, you have to think about signle app, that can > display help for both GTK/Qt as well as the rest of the world. unless you write it - it will never happen. both camps will do (and alreayd have done) their own. you can do one - but neither side will use it. welcome to the world fo warring desktops. we can standardize but each mob have their own implimentation of those standards - and you either pick one side or the other or you get a mish-mash of them. you're call as a user. personally i'm happy to just impliment my own stuff for myself and be done with it :) saves me having to choose choose a job .. choose a family.. choose a fucking big television.. choose life. :) > If all you need is internal toolkit help browser - then why bother with > standard? I don't think it will make any sense at all for window manager > to implement "What's it" button which will work only in GTK/QT, and > will not work correctly even on its own interface elements. > > Besides do you actually see all the apps linked as dynamically only > from now onwards? Cos if you link it statically - you do get bloat issue. -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com VA Linux Systems raster@deephackmode.org Mobile Phone: +1 408 887 3163 Work Phone: +1 510 687 7069 From Sasha_Vasko@osca.state.mo.us Mon May 7 17:18:17 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id A78A32E318 for ; Mon, 7 May 2001 17:18:17 -0400 (EDT) Subject: Re: "What's this" To: wm-spec-list@gnome.org From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 16:15:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 04:15:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > Sasha_Vasko@osca.state.mo.us writes: > > > > So what is this exactly we are arguing about ? What is your alternative? > > > > My original thought on this was just a spec for putting the ? button > in the WM decoration. That is, the client would set a hint "I support > what's this" and the WM would send a message if the user clicked the > what's this button. But the actual help is just within the app. Hmm, is thtat really all that simple? I mean upon receiving such a message app would have to grab pointer. But pointer may still be on titlebar - which is window Managers area of resposibility. Just as well user mayhave gone and quickly clicked somewhere else, while "What's this" message was traveling from window manager to client app. > The more ambitious idea is that clicking what's this works for the > entire desktop. This would require a protocol similar to > drag-and-drop, which would normally be implemented in toolkits (since > the only people who no longer use toolkits are people writing window > managers, pretty much, and even the newer WMs use a toolkit whenever > they want to display dialogs and such). > > This would work similar to drag-and-drop; a client would enter what's > this mode (grab pointer, change cursor); somehow notify other clients > that the mode was entered so they could highlight targets; as you > moved the pointer around, it would change to indicate whether you were > on a target; when you then clicked on a target, the target would > receive some sort of message and reply back to the whatsthis-mode > owner app that it should release the grab and leave the mode. well, that could be achieved by using same XDND with some custom Action type (AFAIK). BTW XDND does uses selection :) > There is a problem with inconsistency between toolkits, but this same > problem exists for all aspects of toolkit look-and-feel, and it can be > solved via theme coordination in the same way we'll solve e.g. button > appearance. Heh, still idea of linking whole HTML widget into tiny clock app for the sole purpose of being able to display some short info strikes me as monstrous. > > Havoc > Sasha Vasko From damon@watchland.org Fri May 4 19:33:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from over.watchland.org (WATCHLAND.ORG [208.138.115.93]) by mail.gnome.org (Postfix) with ESMTP id 6B8112BB87 for ; Fri, 4 May 2001 19:33:13 -0400 (EDT) Received: from debian ([192.168.1.2] ident=mail) by over.watchland.org with esmtp (Exim 3.12 #1 (Debian)) id 14vpAE-0004ey-00; Fri, 04 May 2001 19:39:10 -0400 Received: from damon by debian with local (Exim 3.12 #1 (Debian)) id 14vpJH-00040c-00; Fri, 04 May 2001 19:48:31 -0400 Date: Fri, 4 May 2001 19:48:31 -0400 From: Damon McGraw To: Havoc Pennington Cc: Cristian Tibirna , wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010504194831.A15323@watchland.org> References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hp@redhat.com on Fri, May 04, 2001 at 06:29:42PM -0400 Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification IIRC Windows provides only the "what's this" for the current application and then only if context help is available for the widget that you click on. This help is also available (in most apps) by pressing F1 when the widget has focus. Having it available for the whole screen would be a plus (that way you could get it for panel applets as well as full apps). But wouldn't it make more sense if the button (or whatever) to activate it wasn't in a app? Perhaps somewhere on the panel or something instead? Damon ++ 04/05/01 18:29 -0400 - Havoc Pennington: > > Cristian Tibirna writes: > > Isn't this in the new NET spec already? > > > > I don't believe so, as Elliot says. > > I'm thinking of a protocol to do it; either a simple one so you could > click ? on a window and get help for stuff inside that window > (relatively easy) or a more complex thing so you can get help anywhere > on the screen. I'm not sure which one Windows has, actually. > > Havoc > > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list From mrogers@cs.ucl.ac.uk Mon May 7 16:31:51 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from clustermail.minx.net.uk (node-1.minx.net.uk [212.85.249.131]) by mail.gnome.org (Postfix) with ESMTP id 61DDD2C865 for ; Mon, 7 May 2001 16:31:51 -0400 (EDT) Received: from [212.1.154.68] (helo=dexter) by clustermail.minx.net.uk with esmtp (Exim 3.22 #2) id 14wri8-0005JB-00; Mon, 07 May 2001 21:34:35 +0100 Received: from michael by dexter with local (Exim 3.12 #1 (Debian)) id 14wrQv-00005C-00; Mon, 07 May 2001 21:16:41 +0100 Date: Mon, 7 May 2001 21:16:41 +0100 To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010507211641.B253@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sasha_Vasko@osca.state.mo.us on Mon, May 07, 2001 at 02:30:19PM -0500 From: Michael Rogers Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, May 07, 2001 at 02:30:19PM -0500, Sasha_Vasko@osca.state.mo.us wrote: > What cursor feedback exactly are you talking about. Care to provide some > definition ? Or did I miss something ? Besides any cursor manipulations > by client apps are highly discouraged in X. I think the idea is this: When the user clicks on the "What's this?" button, the owner of the button (let's call it the help client) grabs the pointer. Whenever the pointer enters a new window, the help client sends a message to that window. The owner of the window can install a new cursor to indicate that help is available for that widget (similar to the way DnD targets can identify themselves). Old toolkits will not understand the message, so the cursor will not change, so the user will know that no help is available. When the pointer leaves the window, the help client sends another message so the old cursor can be reinstalled. (The client should reinstall the old cursor after a few seconds if no messages are received from the help client, in case the help client has crashed.) When the user clicks on a widget, the help client sends a message to the clicked window and releases the pointer. The clicked widget can show simple tooltip-style help, or launch a standalone help browser if necessary. Neither method involves much bloat. The client doesn't need its own help browser. It could check the value of some environment variable / X resource / GConf resource to find out which app to launch, but that's really outside the scope of the WM spec (although it should probably be standardised in another freedesktop document). Michael From julian.adams@gmx.net Wed May 9 04:17:47 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from cmailg7.svr.pol.co.uk (cmailg7.svr.pol.co.uk [195.92.195.177]) by mail.gnome.org (Postfix) with ESMTP id D43272BB23 for ; Wed, 9 May 2001 04:17:46 -0400 (EDT) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14xPAF-0008AM-00; Wed, 09 May 2001 09:17:43 +0100 Received: from modem-33.leopard-shark.dialup.pol.co.uk ([62.137.37.161] helo=babybel.at_home) by mail18.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14xPAD-0003pp-00; Wed, 09 May 2001 09:17:42 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Julian Adams Reply-To: julian.adams@gmx.net To: Havoc Pennington Subject: Re: Publish revised spec ? Date: Wed, 9 May 2001 09:17:25 +0100 X-Mailer: KMail [version 1.2] Cc: Owen Taylor , wm-spec-list@gnome.org References: <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <01050909172500.07084@babybel.at_home> Content-Transfer-Encoding: 8bit Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Friday 04 May 2001 14:29, Havoc Pennington wrote: > I think I already dumped it on the web page a week or so ago... hope > this doesn't upset anyone. Maybe we can do an announce, if the changes > are interesting enough. > > Havoc Added a change history for 1.1. The changes are very dull, but I did it for completeness (and so you can just scan the change history). Let's get this up on the web as 1.1. Diff below: cvs -z3 diff -u wm-spec.sgml Index: wm-spec.sgml =================================================================== RCS file: /home/freedesktop/wm-spec/wm-spec.sgml,v retrieving revision 1.11 diff -u -r1.11 wm-spec.sgml --- wm-spec.sgml 2001/04/22 10:14:49 1.11 +++ wm-spec.sgml 2001/05/09 02:51:04 @@ -1167,6 +1167,32 @@ Change history + Changes since 1.0 + + +Fix doctype, add author info, update data. + + +Change specification description wording to be more inclusive, and to reflect the joint nature of the specification. + + +Fix miscellaneous typographical, grammar and spelling errors. + + +Clarified _NET_SUPPORTED to include ALL atoms, not just the property names. + + +Various corrections to use of MUST and SHOULD. + + +Fix problem in _NET_WM_ICON where 'bytes' should have been 'cardinals' + + +Replaced ISO-8559-1 characters with entities. + + + + Changes since 1.0pre5 From Sasha_Vasko@osca.state.mo.us Wed May 9 09:59:39 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 2A4A82BF61 for ; Wed, 9 May 2001 09:59:39 -0400 (EDT) Subject: Re: "What's this" To: Sasha_Vasko@osca.state.mo.us, Michael Rogers Cc: wm-spec-list@gnome.org From: Sasha_Vasko@osca.state.mo.us Date: Wed, 9 May 2001 08:56:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/09/2001 08:56:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, May 07, 2001 at 02:30:19PM -0500, Sasha_Vasko@osca.state.mo.us wrote: > > What cursor feedback exactly are you talking about. Care to provide some > > definition ? Or did I miss something ? Besides any cursor manipulations > > by client apps are highly discouraged in X. > > I think the idea is this: > > When the user clicks on the "What's this?" button, the owner of the button > (let's call it the help client) grabs the pointer. Whenever the pointer > enters a new window, the help client sends a message to that window. The > owner of the window can install a new cursor to indicate that help is You cannot install new cursor since help client has an active grab on the pointer at the moment > available for that widget (similar to the way DnD targets can identify > themselves). Old toolkits will not understand the message, so the cursor > will not change, so the user will know that no help is available. When > the pointer leaves the window, the help client sends another message so > the old cursor can be reinstalled. (The client should reinstall the old > cursor after a few seconds if no messages are received from the help > client, in case the help client has crashed.) You cannot query what was the old cursor > When the user clicks on a widget, the help client sends a message to the > clicked window and releases the pointer. Actuall protocol used by XDND is much more complicated and includes complicated 2-way message exchange, and it does takes ownership of selection, but mostly for the purpose of avoiding possible situation where 2 DND operations will be attempted at the same time. Like I said before - "what's this" stuff could be done by simply utilizing XDND protocol with custom action, like _NET_XdndActionWhatsThis for example. > The clicked widget can show simple tooltip-style help, or launch a > standalone help browser if necessary. Neither method involves much > bloat. The client doesn't need its own help browser. It could check the > value of some environment variable / X resource / GConf resource to find > out which app to launch, but that's really outside the scope of the WM > spec (although it should probably be standardised in another freedesktop > document). yes it is outside of the scope of this specs. Still, just as a general idea, think about it: wouldnot that be nice if there was a single app that could have given you a help on each and every client/widget on the desktop in some standard view, no matter if the widget is from GTK or from KDE or other place ? Maybe not exactly a "Whats this" feature - sort of like man page browser only smart enough to query what text should be displayed from the client window by itself - with no user typing in a name to look up. > Michael Cheers Sasha Vasko From mrogers@cs.ucl.ac.uk Wed May 9 15:13:21 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from clustermail.minx.net.uk (node-3.minx.net.uk [212.85.249.133]) by mail.gnome.org (Postfix) with ESMTP id EA82C2DE3B for ; Wed, 9 May 2001 15:13:20 -0400 (EDT) Received: from [212.1.141.153] (helo=dexter) by clustermail.minx.net.uk with esmtp (Exim 3.22 #4) id 14xZRo-00038f-00 for wm-spec-list@gnome.org; Wed, 09 May 2001 20:16:34 +0100 Received: from michael by dexter with local (Exim 3.12 #1 (Debian)) id 14xZM7-00007O-00 for ; Wed, 09 May 2001 20:10:39 +0100 Date: Wed, 9 May 2001 20:10:39 +0100 To: wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010509201039.D252@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sasha_Vasko@osca.state.mo.us on Wed, May 09, 2001 at 08:56:29AM -0500 From: Michael Rogers Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Wed, May 09, 2001 at 08:56:29AM -0500, Sasha_Vasko@osca.state.mo.us wrote: > You cannot install new cursor since help client has an active grab on the > pointer at the moment Sorry, I didn't realise (although that makes sense now I think about it!). Maybe XDnD is the best way to do it then. > Still, just as a general idea, think about it: wouldnot that be nice if > there was a single app that could have given you a help on each and > every client/widget on the desktop in some standard view, no matter if > the widget is from GTK or from KDE or other place ? Maybe not exactly > a "Whats this" feature - sort of like man page browser only smart > enough to query what text should be displayed from the client window by > itself - with no user typing in a name to look up. But Gnome and KDE would create their own implementations so you would still have the problem of choosing which one to launch! :) We should provide a way for the user to choose which app will be used to display help, in a way that any desktop environment or WM can understand. The user gets the "standard view", and the DEs get to bitch about who provides the best help browser. :) One possibility is to use ~/.mime.types - the user can choose which app should handle the content type x-documentation/man, for example, and when an app wants to display a man page it can launch the program that's registered to handle that MIME type. You would have different MIME types for different types of documentation (x-documentation/info, x-documentation/html, x-documentation/plain), which might point to the same versatile help browser or to standalone viewers. Michael From julian.adams@gmx.net Fri May 4 05:45:10 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by mail.gnome.org (Postfix) with SMTP id 343B92CEBC for ; Fri, 4 May 2001 05:43:11 -0400 (EDT) Received: (qmail 31843 invoked by uid 0); 4 May 2001 09:43:09 -0000 Received: from unknown (HELO JADAMS.gmx.net) (212.74.3.86) by mail.gmx.net (mail09) with SMTP; 4 May 2001 09:43:09 -0000 Message-Id: <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> X-Sender: zaftig.freeserve.co.uk@pop.freeserve.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 04 May 2001 10:46:34 +0100 To: Owen Taylor From: julian adams Subject: Re: Publish revised spec ? Cc: wm-spec-list@gnome.org In-Reply-To: References: <01042216381500.00718@babybel.at_home> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification I'll write up the changes over the next week, and then we can put it out. julian At 19:55 23/04/2001, Owen Taylor wrote: >Julian Adams writes: > > > I've commited a minor revision to the spec in CVS, clarifying=20 > _NET_SUPPORTED as > > discussed before. (diff below) > > > > I think this version of the spec (mainly David Wheeler's corrections)=20 > should > > get put out as a release as there are essential clarifications and=20 > corrections > > (e.g. the icon format). > >For people's reference, I've appended the diff -u betwen 1.0 and the >current version, with annotations to point what ones are spelling/etc. >and what ones are significant. > >The Changes section at the end needs to be updated to reflect the >3 significant changes. > >I think putting out a new revision at this point should be fine, >assuming everyone agrees with these changes. > >Regards, > Owen > > > diff -u -r1.9 -r1.11 > --- wm-spec.sgml 2000/11/22 21:40:56 1.9 > +++ wm-spec.sgml 2001/04/22 10:14:49 1.11 > @@ -1,22 +1,36 @@ > - + ]> >
> - > + > + > + > + X Desktop Group > + > + > Extended Window Manager Hints > -5 November 2000 > - > +10 March 2001 > + > >Fix doctype, add author info, update data. > > > Introduction > > Version > > -This spec is version 1.0. > +This is version 1.1 of the Extended Window Manager Hints (EWMH) spec, > +updated 10 March 2001. > >Update version > > > > What is this spec? > > -This spec defines interactions between window managers, applications=20 > and the utilities that form part of a desktop environment. It builds on= =20 > the ICCCM [2], which defines wm/client interactions at a lower level. It= =20 > was born out of a need to replace the original Gnome WM specification,=20 > although this specification has been designed to be independent of any=20 > one desktop environment. > +This spec defines interactions between window managers, applications, > +and the utilities that form part of a desktop environment. It builds > +on the ICCCM [2], which defines WM (window manager) interactions at a > +lower level. The ICCCM does not provide ways to implement many > +features that modern desktop users expect. The GNOME and KDE desktop > +projects originally developed their own extensions to the ICCCM to > +support these features; this spec replaces those custom extensions > +with a standardized set of ICCCM additions that any desktop > +environment can adopt. > >Change wording to be more inclusive, and to reflect the joint nature >of the specification. > > > > > @@ -82,7 +96,7 @@ > > > Modality > -The Window Manager_TRANSIENT_FOR hint of the ICCCM allows=20 > clients to specify that a > +The Window Manager _TRANSIENT_FOR hint of the ICCCM allows=20 > clients to specify that a > >Fix missing space. > > toplevel window may be closed before the client finishes. A typical=20 > example > of a transient window is a dialog. Some dialogs can be open for a=20 > long time, > while the user continues to work in the main window. Other dialogs=20 > have to be > @@ -183,7 +197,7 @@ > > > Animated iconification > -Some Window Managers display some form of animation when=20 > (de-)iconfying a window. > +Some Window Managers display some form of animation when=20 > (de-)iconifying a window. > >Spelling fix. > > This may be a line drawing connecting the corners of the window with > the corners of the icon or the window may be opaquely moved and resized > on some trajectory joining the window location and the icon=20 > location. > @@ -249,8 +263,10 @@ > ]]> > > This property MUST be set by the Window Manager to indicate which hints= it > -supports. This assumes that backwards incompatible changes will not=20 > be made > -to the hints (without being renamed). > +supports. For example: considering _NET_WM_STATE > +both this atom and all supported states e.g. _NET_WM_STATE_MODAL, > +_NET_WM_STATE_STICKY, would be listed. This assumes that backwards > +incompatible changes will not be made to the hints (without being=20 > renamed). > >Change to include ALL atoms, not just the property names. > > > _NET_CLIENT_LIST > @@ -286,7 +302,7 @@ > The Window Manager is free to honor or reject this request. If request= =20 > is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of=20 > desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of=20 > desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and=20 > _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES=20 > property MAY remain unchanged. > > > -If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out= =20 > of the new range of of available desktops, then this MUST must be set to= =20 > the last available desktop from the new set. If number of desktops is=20 > shrinking then clients that are still present on desktops, that are out=20 > of the new range, MUST be moved to the very last desktop from the new=20 > set. For these _NET_WM_DESKTOP MUST be updated. > +If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out= =20 > of the new range of available desktops, then this MUST be set to the last= =20 > available desktop from the new set. If number of desktops is shrinking=20 > then clients that are still present on desktops, that are out of the new= =20 > range, MUST be moved to the very last desktop from the new set. For these= =20 > _NET_WM_DESKTOP MUST be updated. > >Remove excess 'of', 'must'. > > > > > @@ -577,7 +593,7 @@ > _NET_WM_WINDOW_TYPE, ATOM[]/32 > ]]> > > -This MUST be set by the Client before mapping, to a list of atoms=20 > indicating > +This SHOULD be set by the Client before mapping, to a list of atoms=20 > indicating > the functional type of the window. This property SHOULD be used by=20 > the window > manager in determining the decoration, stacking position and other=20 > behaviour > of the window. The Client SHOULD specify window types in order of=20 > preference > >Change MUST to SHOULD. > > @@ -757,7 +773,7 @@ > > > This is an array of 32bit packed CARDINAL ARGB with high byte being A,= low > -byte being B. First two bytes are width, height. Data is in rows,=20 > left to > +byte being B. First two cardinals are width, height. Data is in=20 > rows, left to > right and top to bottom. > > > >Fix problem where 'bytes' should have been 'cardinals' > > @@ -1062,10 +1078,10 @@ > > > > -[1] ICCCM Version 2.0, =A74.1.2.3 and =A74.1.5 > +[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 > > > -[2] ICCCM Version 2.0, =A74.2.3 > +[2] ICCCM Version 2.0, §4.2.3 > >Replace iso-8559-1 with entitities. From hp@redhat.com Fri May 4 09:27:31 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 6B5B12DBD3 for ; Fri, 4 May 2001 09:27:31 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44DTaw07396; Fri, 4 May 2001 09:29:36 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: julian adams Cc: Owen Taylor , wm-spec-list@gnome.org Subject: Re: Publish revised spec ? References: <01042216381500.00718@babybel.at_home> <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> From: Havoc Pennington Date: 04 May 2001 09:29:36 -0400 In-Reply-To: julian adams's message of "Fri, 04 May 2001 10:46:34 +0100" Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification julian adams writes: > I'll write up the changes over the next week, and then we can put it out. > I think I already dumped it on the web page a week or so ago... hope this doesn't upset anyone. Maybe we can do an announce, if the changes are interesting enough. Havoc From hp@redhat.com Fri May 4 12:52:19 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 069812E957 for ; Fri, 4 May 2001 12:52:16 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44GsQd27078; Fri, 4 May 2001 12:54:26 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: wm-spec-list@gnome.org Subject: "What's this" From: Havoc Pennington Date: 04 May 2001 12:54:25 -0400 Message-ID: Lines: 11 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Hi, Has anyone implemented or considered implementing the Windows feature where the frame has a ? on it, and you click that to enter "What's this" mode and can then get help on stuff in the window? (Or is it a global mode and you can get help on anything onscreen?) Seems like we could have a simple protocol enabling this. Havoc From tibirna@kde.org Fri May 4 13:12:23 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by mail.gnome.org (Postfix) with ESMTP id C51302DFB4 for ; Fri, 4 May 2001 13:11:29 -0400 (EDT) Received: from there ([64.229.234.15]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> for ; Fri, 4 May 2001 13:11:29 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Cristian Tibirna Organization: KDE To: wm-spec-list@gnome.org Subject: Re: "What's this" Date: Fri, 4 May 2001 13:12:02 -0400 X-Mailer: KMail [version 1.2.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Friday 04 May 2001 12:54, you wrote: > Hi, > > Has anyone implemented or considered implementing the Windows feature > where the frame has a ? on it, and you click that to enter "What's > this" mode and can then get help on stuff in the window? (Or is it a > global mode and you can get help on anything onscreen?) > KDE has it all over the place. You actually get help only for the widgets for which you write "what's this" information explicitely, in KDE. But I believe this could be implemented otherwise in other places. > Seems like we could have a simple protocol enabling this. Hmm? Isn't this in the new NET spec already? -- Cristian Tibirna .. tibirna@sympatico.ca PhD Student .. ctibirna@giref.ulaval.ca .. www.giref.ulaval.ca/~ctibirna KDE contact - Canada .. tibirna@kde.org .. www.kde.org From sopwith@redhat.com Fri May 4 15:14:08 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 73E892C934 for ; Fri, 4 May 2001 15:14:08 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f44JE8S03930 for ; Fri, 4 May 2001 15:14:08 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Fri, 4 May 2001 15:14:07 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Subject: Re: "What's this" In-Reply-To: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Fri, 4 May 2001, Cristian Tibirna wrote: > > Has anyone implemented or considered implementing the Windows feature > > where the frame has a ? on it, and you click that to enter "What's > > this" mode and can then get help on stuff in the window? (Or is it a > > global mode and you can get help on anything onscreen?) > > KDE has it all over the place. You actually get help only for the widgets for > which you write "what's this" information explicitely, in KDE. But I believe > this could be implemented otherwise in other places. > > > Seems like we could have a simple protocol enabling this. > > Hmm? > > Isn't this in the new NET spec already? KDE just uses the Qt hack that does it in one process only. Doing that is easy and irrelevant to this list. A reasonable requirement would be for a "what's this" solution to work inter-application, which would mean coming up with an X protocol to do it. I started looking at this for gnome-libs once - the way I was thinking of doing it was having cursor feedback similar to DnD to point out areas that help can be given for, plus a way to tell the clicked-on area to show its help, once it is clicked. -- Elliot These three lines are for sale at the rate of $50/month. From hp@redhat.com Fri May 4 18:28:30 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 11E322BBE4 for ; Fri, 4 May 2001 18:28:29 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44MTgq03942; Fri, 4 May 2001 18:29:42 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Cristian Tibirna Cc: wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> From: Havoc Pennington Date: 04 May 2001 18:29:42 -0400 In-Reply-To: Cristian Tibirna's message of "Fri, 4 May 2001 13:12:02 -0400" Message-ID: Lines: 13 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Cristian Tibirna writes: > Isn't this in the new NET spec already? > I don't believe so, as Elliot says. I'm thinking of a protocol to do it; either a simple one so you could click ? on a window and get help for stuff inside that window (relatively easy) or a more complex thing so you can get help anywhere on the screen. I'm not sure which one Windows has, actually. Havoc From hp@redhat.com Fri May 4 19:56:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 4110A2BB87 for ; Fri, 4 May 2001 19:56:13 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44NvbY14667; Fri, 4 May 2001 19:57:37 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Damon McGraw Cc: Cristian Tibirna , wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> <20010504194831.A15323@watchland.org> From: Havoc Pennington Date: 04 May 2001 19:57:37 -0400 In-Reply-To: Damon McGraw's message of "Fri, 4 May 2001 19:48:31 -0400" Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Damon McGraw writes: > > Having it available for the whole screen would be a plus (that way you > could get it for panel applets as well as full apps). But wouldn't it > make more sense if the button (or whatever) to activate it wasn't in a > app? Perhaps somewhere on the panel or something instead? > Seems likely that's not really an issue the protocol would need to address - there would be some way to say "enter whatsthis mode" and the window manager or panel or whatever could provide a button that did that. Havoc From l.lunak@sh.cvut.cz Sat May 5 05:11:16 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mail.gnome.org (Postfix) with ESMTP id AABCF2CDA1 for ; Sat, 5 May 2001 05:11:15 -0400 (EDT) Received: from stoupa.sh.cvut.cz (stoupa.sh.cvut.cz [147.32.127.196]) by service.sh.cvut.cz (8.9.3/SH) with ESMTP id LAA15174 for ; Sat, 5 May 2001 11:11:14 +0200 Received: from there (seli@seli.sh.cvut.cz [147.32.122.38]) by stoupa.sh.cvut.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id LAA01583 for ; Sat, 5 May 2001 11:11:14 +0200 Message-Id: <200105050911.LAA01583@stoupa.sh.cvut.cz> Content-Type: text/plain; charset="iso-8859-2" From: Lubos Lunak To: wm-spec-list@gnome.org Subject: Re: "What's this" Date: Sat, 5 May 2001 11:11:12 +0200 X-Mailer: KMail [version 1.2.1] References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Dne so 5. kv=ECten 2001 00:29 jste napsal(a): > Cristian Tibirna writes: > > Isn't this in the new NET spec already? > > I don't believe so, as Elliot says. > > I'm thinking of a protocol to do it; either a simple one so you could > click ? on a window and get help for stuff inside that window > (relatively easy) or a more complex thing so you can get help anywhere > on the screen. I'm not sure which one Windows has, actually. Win2k has 'what's this' only for the active window, the same way it's in= =20 KDE/Qt ( which is IMHO good enough ). > > Havoc > Lubos Lunak -- l.lunak@email.cz ; l.lunak@kde.org http://dforce.sh.cvut.cz/~seli From otaylor@redhat.com Sat May 5 10:30:14 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from fresnel.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 5F7C52E087 for ; Sat, 5 May 2001 10:30:14 -0400 (EDT) Received: by fresnel.labs.redhat.com (Postfix, from userid 2181) id DB90A241C6D; Sat, 5 May 2001 10:30:13 -0400 (EDT) To: wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> <200105050911.LAA01583@stoupa.sh.cvut.cz> From: Owen Taylor Date: 05 May 2001 10:30:13 -0400 In-Reply-To: Lubos Lunak's message of "Sat, 5 May 2001 11:11:12 +0200" Message-ID: Lines: 47 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Lubos Lunak writes: > Dne so 5. kv=ECten 2001 00:29 jste napsal(a): > > Cristian Tibirna writes: > > > Isn't this in the new NET spec already? > > > > I don't believe so, as Elliot says. > > > > I'm thinking of a protocol to do it; either a simple one so you could > > click ? on a window and get help for stuff inside that window > > (relatively easy) or a more complex thing so you can get help anywhere > > on the screen. I'm not sure which one Windows has, actually. >=20 > Win2k has 'what's this' only for the active window, the same way it's in= =20 > KDE/Qt ( which is IMHO good enough ). Considering that: - "What's this" needs to be activated at least from the window manager title bar. - "What's this" needs to work across embedded subwindows. I don't think you get any essential simplification in implementation from allowing it only in a single window. And I think it's easy to do better than Windows in this respect: - Provide "what's this" globally, and in particular on desktop features such as the taskbar and desktop icons. - Provide feedback during the "what's this operation". (Having to guess what has help, and then restart the operation is the thing I found most annoying trying out this feature in Windows.) (The simplest feedback is simply a yes/no indication as in DND.=20 This is easy to implement and easy to standardize. I suspect it's possible to do better than this, either by providing some visual clue as to what elements have help, or by displaying the help immediately on mouse-over; but I'm not sure that the extra complexity would be worth it.) Regards, Owen From M.Rogers@cs.ucl.ac.uk Sat May 5 11:34:23 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.gnome.org (Postfix) with SMTP id 415192E0AD for ; Sat, 5 May 2001 11:34:23 -0400 (EDT) Received: from moorgate.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 5 May 2001 16:34:19 +0100 To: wm-spec-list@gnome.org Subject: Re: "What's this" In-reply-to: Your message of "04 May 2001 19:57:37 EDT." Date: Sat, 05 May 2001 16:34:18 +0100 Message-ID: <892.989076858@cs.ucl.ac.uk> From: Michael ROGERS Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification >Seems likely that's not really an issue the protocol would need to >address - there would be some way to say "enter whatsthis mode" and >the window manager or panel or whatever could provide a button that >did that. How about this: When the help button is pressed, the help client (could be the WM or a panel applet) grabs the pointer and installs a ? cursor. When the user clicks on an item, the help client sends a client message to the clicked window and releases the pointer. Clients that don't understand the message will ignore it; clients that understand it can display help. This could be a top-level help window, or one of those popup explanations that Windows uses, which don't disappear until you click on something. (Grab the pointer and use redirect override on the tooltip window?) This mechanism could be tied into the existing KDE help system (Qt would detect the client messages and invoke the existing mechanism), so a panel applet or WM could trigger the context-sensitive help attached to KDE widgets. Michael From jg@pa.dec.com Sat May 5 22:05:16 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.gnome.org (Postfix) with ESMTP id 113442CA71 for ; Sat, 5 May 2001 22:05:16 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 44D031C81; Sat, 5 May 2001 21:05:15 -0500 (CDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E7DAFD37; Sat, 5 May 2001 21:05:14 -0500 (CDT) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 897AC42F; Sat, 5 May 2001 22:05:14 -0400 (EDT) Received: from src-mail.pa.dec.com (src-mail.pa.dec.com [16.4.16.35]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 00F6E5EA; Sat, 5 May 2001 22:05:13 -0400 (EDT) Received: by src-mail.pa.dec.com; id TAA09428; Sat, 5 May 2001 19:05:13 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Received: (from pachydrm@localhost) by pachyderm.pa.dec.com (8.11.1/8.11.1) id f4625DU497096; Sat, 5 May 2001 19:05:13 -0700 (PDT) Date: Sat, 5 May 2001 19:05:13 -0700 (PDT) Message-Id: <200105060205.f4625DU497096@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Elliot Lee Cc: wm-spec-list@gnome.org In-Reply-To: Subject: Re: "What's this" Mime-Version: 1.0 Content-Type: text/plain Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification All that is really needed is to decorate the widget windows with the class and instance data from the toolkit, and then one can have an external process do the display. We need that data for things like "Hands off X" to work, and doing it externally means that it can be done to almost any application, independent of the author, in a uniform fashion across toolkits. - Jim > Sender: wm-spec-list-admin@gnome.org > From: Elliot Lee > Date: Fri, 4 May 2001 15:14:07 -0400 (EDT) > To: > Subject: Re: "What's this" > ----- > On Fri, 4 May 2001, Cristian Tibirna wrote: > > > > Has anyone implemented or considered implementing the Windows feature > > > where the frame has a ? on it, and you click that to enter "What's > > > this" mode and can then get help on stuff in the window? (Or is it a > > > global mode and you can get help on anything onscreen?) > > > > KDE has it all over the place. You actually get help only for the widgets > for > > which you write "what's this" information explicitely, in KDE. But I believe > > this could be implemented otherwise in other places. > > > > > Seems like we could have a simple protocol enabling this. > > > > Hmm? > > > > Isn't this in the new NET spec already? > > KDE just uses the Qt hack that does it in one process only. Doing that is > easy and irrelevant to this list. A reasonable requirement would be for a > "what's this" solution to work inter-application, which would mean coming > up with an X protocol to do it. > > I started looking at this for gnome-libs once - the way I was thinking of > doing it was having cursor feedback similar to DnD to point out areas that > help can be given for, plus a way to tell the clicked-on area to show its > help, once it is clicked. > > -- Elliot > These three lines > are for sale > at the rate of $50/month. > > > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com From hp@redhat.com Sun May 6 01:28:10 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 33B1C2CE26 for ; Sun, 6 May 2001 01:28:10 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f465UFd15508; Sun, 6 May 2001 01:30:15 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: jg@pa.dec.com (Jim Gettys) Cc: Elliot Lee , wm-spec-list@gnome.org Subject: Re: "What's this" References: <200105060205.f4625DU497096@pachyderm.pa.dec.com> From: Havoc Pennington Date: 06 May 2001 01:30:15 -0400 In-Reply-To: jg@pa.dec.com's message of "Sat, 5 May 2001 19:05:13 -0700 (PDT)" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification jg@pa.dec.com (Jim Gettys) writes: > All that is really needed is to decorate the widget windows with > the class and instance data from the toolkit, and then one can > have an external process do the display. One problem with that is that we already have a bunch of widgets (or useful-to-communicate-with widget subportions such as sheet cells) that don't have an X window. > We need that data for things like "Hands off X" to work, > and doing it externally means that it can be done to almost any > application, independent of the author, in a uniform fashion > across toolkits. If "Hands off X" is speech recognition stuff, the general GTK plan here (for in-process) is the accessibility API Sun is contributing. Then there is some out-of-process protocol yet to be defined, and a GTK module would be loaded into apps which exported the data obtained from the accessibility API to an alternative/supplemental input/output mechanism living in another process. I think "what's this" is very simple; you just have some way of signaling that you're in "what's this" mode, toolkits highlight widgets with available help; and you send some sort of message to whatever window gets clicked on, and the toolkit pops up the help. App authors just call widget_set_whats_this() and the toolkit magically makes it work. Havoc From olivier.chapuis@free.fr Sun May 6 09:02:42 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by mail.gnome.org (Postfix) with ESMTP id A50FA2BE20 for ; Sun, 6 May 2001 09:02:41 -0400 (EDT) Received: from snoopy.parislyon (paris11-nas2-42-12.dial.proxad.net [212.27.42.12]) by postfix2-1.free.fr (Postfix) with ESMTP id 80AD7C0E9; Sun, 6 May 2001 15:02:39 +0200 (CEST) Received: from snoopy.parislyon (snoopy.parislyon [127.0.0.1]) by snoopy.parislyon (Postfix) with SMTP id B1020242ED; Sun, 6 May 2001 14:54:53 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Olivier Chapuis To: fvwm-announce@fvwm.org, wm-spec-list@gnome.org Subject: fvwm-ewmh-0.1 is released Date: Sun, 6 May 2001 14:54:52 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01050614545200.26369@snoopy.parislyon> Content-Transfer-Encoding: 8bit Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification I am glad to announce the first version of fvwm-ewmh. fvwm-ewmh is constituted by a module, FvwmNetHints, and a patch against the last FVWM beta version (a stable candidate): fvwm-2.3.32. With these FVWM can handle Extended Window Manager Hints from the freedesktop group. This allows, for example, to run FVWM with KDE version 2. This package is alpha, however, it works not so bad on my machine. I announce this release with the hope to get some feedback before releasing version 0.2 which will be released a few days after fvwm-2.4.0 (with no announce to this list). Home Page (Download, Installation, Running, FAQ): http://fvwm-ewmh.sourceforge.net/ Screen Shots: http://fvwm-ewmh.sourceforge.net/screenshots/ Regards, Olivier From Sasha_Vasko@osca.state.mo.us Mon May 7 12:16:56 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 26C0A2DBB2 for ; Mon, 7 May 2001 12:16:56 -0400 (EDT) Subject: Re: "What's this" To: wm-spec-list@gnome.org, Michael ROGERS From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 11:13:56 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 11:14:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > >Seems likely that's not really an issue the protocol would need to > >address - there would be some way to say "enter whatsthis mode" and > >the window manager or panel or whatever could provide a button that > >did that. > > How about this: > > When the help button is pressed, the help client (could be the WM or a > panel applet) grabs the pointer and installs a ? cursor. When the user > clicks on an item, the help client sends a client message to the clicked > window and releases the pointer. Clients that don't understand the > message will ignore it; clients that understand it can display help. Clients should not be bothered with displaying help, unless you want to bloat all of them with basically identical help rendering code. Much cleaner approach would be for single help app. It would query client about context of the mouse click ( basically send it message like: ) on which client should respond with meaningfull text data identifying what help should be displayed - something like . help app then goes and at all known to it locations for this particular information. In case client does not support/respond to thins protocol - then help app simply falls back to using res_name, res_class from client's hints, and goes looking for the man page for this client. X selections would be a good way to implement such a protocol. Compliant clients should acqure ownership of the selection on its top level window something like _NET_HELP. help app then sends them request, passing parameters along in its target property _NET_HELP_REQUEST, created on its own window. And client should respond to it, by placing click context description info into this target property. If client is not an owner of selection _NET_HELP or if it does not respond within reasonable timeout - help app goes on and displays help based on clients Class hints. Something along this lines. > This could be a top-level help window, or one of those popup > explanations that Windows uses, which don't disappear until you click on > something. (Grab the pointer and use redirect override on the tooltip > window?) > > This mechanism could be tied into the existing KDE help system (Qt would > detect the client messages and invoke the existing mechanism), so a > panel applet or WM could trigger the context-sensitive help attached to > KDE widgets. > > Michael > Regards Sasha Vasko From sopwith@redhat.com Mon May 7 12:37:02 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id D79E52CBBE for ; Mon, 7 May 2001 12:37:01 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Gav525322; Mon, 7 May 2001 12:36:57 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 12:36:57 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Jim Gettys Cc: Subject: Re: "What's this" In-Reply-To: <200105060205.f4625DU497096@pachyderm.pa.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Sat, 5 May 2001, Jim Gettys wrote: > All that is really needed is to decorate the widget windows with > the class and instance data from the toolkit, and then one can > have an external process do the display. This is not sufficient to meet the requirements I had in mind. The application whose help is being requested has to be asked to display the help, because it can display it in a manner that best fits the item in question. Also, this approach won't work for widgets without windows... (Not saying that that class/instance info does/doesn't need to be there, of course - if you want it there just file a gtk bug. :-) -- Elliot These three lines are for sale at the rate of $50/month. From sopwith@redhat.com Mon May 7 12:45:02 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 6E5322BAB1 for ; Mon, 7 May 2001 12:45:02 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Giua26941; Mon, 7 May 2001 12:44:56 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 12:44:56 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Cc: , Michael ROGERS Subject: Re: "What's this" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > Clients should not be bothered with displaying help, unless you want to > bloat all of them with basically identical help rendering code. Clients are the only pieces that know how to best display the help. If someone wants to implement the paperclip (whether you like it or not, that case needs to be possible), doing it in the client is the only sane way. If client wishes to use a standardized-help-display-mechanism to show the popup help, then it is entirely possible, but that's a separate problem to be solved - let's not complicate the problem further than it has to be. Right now the only thing to do is find out whether a client has help available for a widget (to provide cursor feedback) and ask the client to provide that help... So, I'm in rough agreement with Havoc on this one, -- Elliot These three lines are for sale at the rate of $50/month. From jg@pa.dec.com Mon May 7 13:20:11 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.gnome.org (Postfix) with ESMTP id 3B3E72BBE0 for ; Mon, 7 May 2001 13:20:11 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 83655CFF; Mon, 7 May 2001 12:20:10 -0500 (CDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4A9A3E18; Mon, 7 May 2001 12:20:10 -0500 (CDT) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id EB7F329B; Mon, 7 May 2001 10:20:09 -0700 (PDT) Received: from src-mail.pa.dec.com (src-mail.pa.dec.com [16.4.16.35]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id DCF0315A; Mon, 7 May 2001 10:20:09 -0700 (PDT) Received: by src-mail.pa.dec.com; id KAA17194; Mon, 7 May 2001 10:20:09 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Received: (from pachydrm@localhost) by pachyderm.pa.dec.com (8.11.1/8.11.1) id f47HK97280588; Mon, 7 May 2001 10:20:09 -0700 (PDT) Date: Mon, 7 May 2001 10:20:09 -0700 (PDT) Message-Id: <200105071720.f47HK97280588@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Elliot Lee Cc: Jim Gettys , wm-spec-list@gnome.org In-Reply-To: Subject: Re: "What's this" Mime-Version: 1.0 Content-Type: text/plain Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > From: Elliot Lee > Date: Mon, 7 May 2001 12:36:57 -0400 (EDT) > To: Jim Gettys > Cc: > Subject: Re: "What's this" > ----- > On Sat, 5 May 2001, Jim Gettys wrote: > > > All that is really needed is to decorate the widget windows with > > the class and instance data from the toolkit, and then one can > > have an external process do the display. > > This is not sufficient to meet the requirements I had in mind. The > application whose help is being requested has to be asked to display the > help, because it can display it in a manner that best fits the item in > question. Yes, but it would get 90%, and would allow for help on toolkits that don't do this at all. So how about this scheme, suitably modified to inform clients, so that they can provide help if need be to cover these cases. > > Also, this approach won't work for widgets without windows... > > (Not saying that that class/instance info does/doesn't need to be there, > of course - if you want it there just file a gtk bug. :-) OK, will do :-). Where is the bug reporting system? - Jim -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com From Sasha_Vasko@osca.state.mo.us Mon May 7 13:27:20 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 70E442BBE0 for ; Mon, 7 May 2001 13:27:20 -0400 (EDT) Subject: Re: "What's this" To: Elliot Lee Cc: From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 12:24:32 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 12:24:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > > > Clients should not be bothered with displaying help, unless you want to > > bloat all of them with basically identical help rendering code. > > Clients are the only pieces that know how to best display the help. If > someone wants to implement the paperclip (whether you like it or not, that > case needs to be possible), doing it in the client is the only sane way. While using proposed selection mechanism, it would be possible for client to respond with some special answer, indicating its desire to "Take over" help displaying. I would estimate, thou, that 95% of Unix/Linux/open source apps will not want to do that. It really is kinda stupid to write a man page, and then code huge piece of code into your application to display basically same information. I understand that this is different for BIG applications like Web Browsers/Word Processors, but we should not be thinking solely about those, and if there is a simple way of implementing generic algorithm, that automagically supports ALL unix applications, without changes required to most of those - we should go with it. Using huge library of man pages is a good thing (TM). > > If client wishes to use a standardized-help-display-mechanism to show the > popup help, then it is entirely possible, but that's a separate problem to > be solved - let's not complicate the problem further than it has to be. > Right now the only thing to do is find out whether a client has help > available for a widget (to provide cursor feedback) and ask the client to > provide that help... Selections mechanism is very simple to implement, and most of those BIG apps that needs it, should already have some selections management code, since things like clipboard are implemented this way. On the other hand standardizing some inferior ad-hoc solution is a nasty, way to go since it will provide a very limited solution (you don't have 2-way communications, so there is no way to find out if app has acknowledged request, and therefore you can't implement any fallback techniques ). And we'll need to live with it till the rest of our lives, and ppl will be pointing fingers, blaming us in very harsh words, and we'll be tearing our hair out, and there will not be a way back, etc. , etc., etc. Sooner or later some 2-way communications will have to be implemented, so why not do it right the first time. It's not like if we don't come up with something today - world collapses. > > So, I'm in rough agreement with Havoc on this one, > -- Elliot Regards Sasha Vasko From sopwith@redhat.com Mon May 7 13:37:20 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 081BF2E1BF for ; Mon, 7 May 2001 13:37:20 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Hb9404620; Mon, 7 May 2001 13:37:09 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 13:37:09 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Cc: Subject: Re: "What's this" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > I would estimate, thou, that 95% of Unix/Linux/open source apps will > not want to do that. It really is kinda stupid to write a man page Applications are free to share help system solutions, but they need to do it outside of this idea. Given that there are many other ways to use a help system beside "what's this" kind of help, and that the "what's this" help will need to be integrated into the other parts of the help system, it does not make sense to involve the help display part of things in this spec. This idea is not about specifying a common help system for displaying help, only about one particular method of requesting help that needs to be interoperable to benefit the user most. > On the other hand standardizing some inferior ad-hoc solution is a > nasty, way to go since it will provide a very limited solution (you > don't have 2-way communications, so there is no way to find out if app > has acknowledged request, and therefore you can't implement any > fallback techniques ). Cursor feedback was part of the requirements I gave. If an app doesn't participate in that, then you can do your fallback stuff. -- Elliot These three lines are for sale at the rate of $50/month. From hp@redhat.com Mon May 7 14:17:59 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 72FA92E249 for ; Mon, 7 May 2001 14:12:14 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f47IEAD22635; Mon, 7 May 2001 14:14:10 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org, Michael ROGERS Subject: Re: "What's this" References: From: Havoc Pennington Date: 07 May 2001 14:14:10 -0400 In-Reply-To: Sasha_Vasko@osca.state.mo.us's message of "Mon, 7 May 2001 11:13:56 -0500" Message-ID: Lines: 24 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Sasha_Vasko@osca.state.mo.us writes: > Clients should not be bothered with displaying help, unless you want to > bloat all of them with basically identical help rendering code. The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. There are two problems with the approach you mention: - people want something higher-level than text in the help, e.g. a simple HTML-like subset with links, etc. - help needs to work within a client even if no "help manager" app is running; i.e. the client needs a fallback implementation in any case, it can't rely on a desktop runtime environment being active. So you can't eliminate the toolkit code in any case. (And Qt already has this code, anyhow.) man pages certainly aren't the kind of help we're discussing here; what's this help is just a paragraph on the specific widget that's been clicked. Sort of longer tooltips, maybe with embedded links to the full documentation for the app. Havoc From Sasha_Vasko@osca.state.mo.us Mon May 7 15:26:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 7E7E72DB6D for ; Mon, 7 May 2001 15:26:13 -0400 (EDT) Subject: Re: "What's this" To: Havoc Pennington Cc: wm-spec-list@gnome.org, Michael ROGERS From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 14:23:25 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:23:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > Sasha_Vasko@osca.state.mo.us writes: > > Clients should not be bothered with displaying help, unless you want to > > bloat all of them with basically identical help rendering code. > > The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. > wait a sec. Are we disscussing "what's this" feature applicable only to toolkits ? If so then I retract all my proposals. I thought that you wanted to be able to get help not only on toolkit windows but universally on any object on the desktop. I don't think that any sane window manager is going to implement its own hyperlinked help browser - the best you can count on is popping up mozilla or term with man page/faqs displayed in it. What that brings you to is that user may get all kinds of help systems from different desktop objects - from GTK apps - one, from QT apps - another and completely different from something else, and nothing at all from most other things. All of those things will have different look and feel, which is not nice. If you really want to implement global help system, you have to think about signle app, that can display help for both GTK/Qt as well as the rest of the world. If all you need is internal toolkit help browser - then why bother with standard? I don't think it will make any sense at all for window manager to implement "What's it" button which will work only in GTK/QT, and will not work correctly even on its own interface elements. Besides do you actually see all the apps linked as dynamically only from now onwards? Cos if you link it statically - you do get bloat issue. > There are two problems with the approach you mention: > > - people want something higher-level than text in the help, > e.g. a simple HTML-like subset with links, etc. It's not difficult to implement help browser that would intelligently distinguish between help available in HTML, XML, man pages or any other format. And in fact man pages could be displayed as a hyperlinked text, and are very nice in that way. > > - help needs to work within a client even if no "help manager" app is > running; i.e. the client needs a fallback implementation in any > case, it can't rely on a desktop runtime environment being active. > So you can't eliminate the toolkit code in any case. (And Qt > already has this code, anyhow.) Well, if globally active help system is not running - then this entire disscussion is not applicable anyways - each client will have to rely upon itself entirely. The interesting implication is that you do not really need window manager involvement at all - you click on desktop icon/menu item-> that will launch help app -> help app grabs pointer and waits for a click -> then it traverses window tree in order to find out any parent window with wm hints set. etc. etc. etc. > man pages certainly aren't the kind of help we're discussing here; > what's this help is just a paragraph on the specific widget that's > been clicked. Sort of longer tooltips, maybe with embedded links to > the full documentation for the app. It still has to be a paragraph out of complete set of docs - and as such I do not see much difficulty in displaying particular topic out of HTML file, or even a man page for that matter. Anyways I just proposed the way it could be implemented using standard X approach. I don't seem to see any other alternative proposals, except for Michael Roger's one , which is basically the same as what I proposed, only with messages instead of selection( which is not good for 2-way communications). So what is this exactly we are arguing about ? What is your alternative? > > Havoc From Sasha_Vasko@osca.state.mo.us Mon May 7 15:33:11 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id D866D2CE3D for ; Mon, 7 May 2001 15:33:08 -0400 (EDT) Subject: Re: "What's this" To: , Elliot Lee Cc: From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 14:30:19 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:30:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > > > I would estimate, thou, that 95% of Unix/Linux/open source apps will > > not want to do that. It really is kinda stupid to write a man page > > Applications are free to share help system solutions, but they need to do > it outside of this idea. Given that there are many other ways to use a > help system beside "what's this" kind of help, and that the "what's this" > help will need to be integrated into the other parts of the help system, > it does not make sense to involve the help display part of things in this > spec. This idea is not about specifying a common help system for > displaying help, only about one particular method of requesting help that > needs to be interoperable to benefit the user most. X Selections is the most standrad and interoperable way to implement such things. It has been specifically designed for this purpose. > > On the other hand standardizing some inferior ad-hoc solution is a > > nasty, way to go since it will provide a very limited solution (you > > don't have 2-way communications, so there is no way to find out if app > > has acknowledged request, and therefore you can't implement any > > fallback techniques ). > > Cursor feedback was part of the requirements I gave. If an app doesn't > participate in that, then you can do your fallback stuff. What cursor feedback exactly are you talking about. Care to provide some definition ? Or did I miss something ? Besides any cursor manipulations by client apps are highly discouraged in X. > -- Elliot From hp@redhat.com Mon May 7 15:50:46 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 5EE832CB80 for ; Mon, 7 May 2001 15:50:46 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f47Jqf908069; Mon, 7 May 2001 15:52:41 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org, Michael ROGERS Subject: Re: "What's this" References: From: Havoc Pennington Date: 07 May 2001 15:52:41 -0400 In-Reply-To: Sasha_Vasko@osca.state.mo.us's message of "Mon, 7 May 2001 14:23:25 -0500" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Sasha_Vasko@osca.state.mo.us writes: > > So what is this exactly we are arguing about ? What is your alternative? > My original thought on this was just a spec for putting the ? button in the WM decoration. That is, the client would set a hint "I support what's this" and the WM would send a message if the user clicked the what's this button. But the actual help is just within the app. The more ambitious idea is that clicking what's this works for the entire desktop. This would require a protocol similar to drag-and-drop, which would normally be implemented in toolkits (since the only people who no longer use toolkits are people writing window managers, pretty much, and even the newer WMs use a toolkit whenever they want to display dialogs and such). This would work similar to drag-and-drop; a client would enter what's this mode (grab pointer, change cursor); somehow notify other clients that the mode was entered so they could highlight targets; as you moved the pointer around, it would change to indicate whether you were on a target; when you then clicked on a target, the target would receive some sort of message and reply back to the whatsthis-mode owner app that it should release the grab and leave the mode. There is a problem with inconsistency between toolkits, but this same problem exists for all aspects of toolkit look-and-feel, and it can be solved via theme coordination in the same way we'll solve e.g. button appearance. Havoc From raster@asterman.com Mon May 7 15:54:37 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from asterman.com (nat-hdqt.valinux.com [198.186.202.17]) by mail.gnome.org (Postfix) with ESMTP id 86D802CB80 for ; Mon, 7 May 2001 15:54:36 -0400 (EDT) Received: (from raster@localhost) by asterman.com (8.11.0/8.11.0) id f47Iuw925915; Mon, 7 May 2001 11:56:58 -0700 Message-Id: <200105071856.f47Iuw925915@asterman.com> Date: Mon, 7 May 2001 11:56:58 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: "What's this" To: Sasha_Vasko@osca.state.mo.us Cc: hp@redhat.com, wm-spec-list@gnome.org, M.Rogers@cs.ucl.ac.uk In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On 7 May, Sasha_Vasko@osca.state.mo.us scribbled: > > > Sasha_Vasko@osca.state.mo.us writes: > > > Clients should not be bothered with displaying help, unless you want to > > > bloat all of them with basically identical help rendering code. > > > > The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. > > > > wait a sec. Are we disscussing "what's this" feature applicable only to > toolkits ? If so then I retract all my proposals. > > I thought that you wanted to be able to get help not only on toolkit > windows > but universally on any object on the desktop. I don't think that any > sane window manager is going to implement its own hyperlinked help I'm not averse to doing it... :) it's kinda fun.. alreayd implimented one for E16 (dox) because i just wanst willing to wait 10 secons for netscape to pop up with help info in it for some simple help docs with inline diagrams and links within the doc... :) the wm doesnt have to actually impliment the cod if you dont want to.. it coudl pass it off to a helper app installed and exec it passing the info along... > browser - the best you can count on is popping up mozilla or term with > man page/faqs displayed in it. What that brings you to is that user may get > all kinds of help systems from different desktop objects - from GTK apps - > one, > from QT apps - another and completely different from something else, > and nothing at all from most other things. All of those things will > have different look and feel, which is not nice. If you really want to > implement global help system, you have to think about signle app, that can > display help for both GTK/Qt as well as the rest of the world. unless you write it - it will never happen. both camps will do (and alreayd have done) their own. you can do one - but neither side will use it. welcome to the world fo warring desktops. we can standardize but each mob have their own implimentation of those standards - and you either pick one side or the other or you get a mish-mash of them. you're call as a user. personally i'm happy to just impliment my own stuff for myself and be done with it :) saves me having to choose choose a job .. choose a family.. choose a fucking big television.. choose life. :) > If all you need is internal toolkit help browser - then why bother with > standard? I don't think it will make any sense at all for window manager > to implement "What's it" button which will work only in GTK/QT, and > will not work correctly even on its own interface elements. > > Besides do you actually see all the apps linked as dynamically only > from now onwards? Cos if you link it statically - you do get bloat issue. -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com VA Linux Systems raster@deephackmode.org Mobile Phone: +1 408 887 3163 Work Phone: +1 510 687 7069 From Sasha_Vasko@osca.state.mo.us Mon May 7 17:18:17 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id A78A32E318 for ; Mon, 7 May 2001 17:18:17 -0400 (EDT) Subject: Re: "What's this" To: wm-spec-list@gnome.org From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 16:15:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 04:15:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > Sasha_Vasko@osca.state.mo.us writes: > > > > So what is this exactly we are arguing about ? What is your alternative? > > > > My original thought on this was just a spec for putting the ? button > in the WM decoration. That is, the client would set a hint "I support > what's this" and the WM would send a message if the user clicked the > what's this button. But the actual help is just within the app. Hmm, is thtat really all that simple? I mean upon receiving such a message app would have to grab pointer. But pointer may still be on titlebar - which is window Managers area of resposibility. Just as well user mayhave gone and quickly clicked somewhere else, while "What's this" message was traveling from window manager to client app. > The more ambitious idea is that clicking what's this works for the > entire desktop. This would require a protocol similar to > drag-and-drop, which would normally be implemented in toolkits (since > the only people who no longer use toolkits are people writing window > managers, pretty much, and even the newer WMs use a toolkit whenever > they want to display dialogs and such). > > This would work similar to drag-and-drop; a client would enter what's > this mode (grab pointer, change cursor); somehow notify other clients > that the mode was entered so they could highlight targets; as you > moved the pointer around, it would change to indicate whether you were > on a target; when you then clicked on a target, the target would > receive some sort of message and reply back to the whatsthis-mode > owner app that it should release the grab and leave the mode. well, that could be achieved by using same XDND with some custom Action type (AFAIK). BTW XDND does uses selection :) > There is a problem with inconsistency between toolkits, but this same > problem exists for all aspects of toolkit look-and-feel, and it can be > solved via theme coordination in the same way we'll solve e.g. button > appearance. Heh, still idea of linking whole HTML widget into tiny clock app for the sole purpose of being able to display some short info strikes me as monstrous. > > Havoc > Sasha Vasko From damon@watchland.org Fri May 4 19:33:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from over.watchland.org (WATCHLAND.ORG [208.138.115.93]) by mail.gnome.org (Postfix) with ESMTP id 6B8112BB87 for ; Fri, 4 May 2001 19:33:13 -0400 (EDT) Received: from debian ([192.168.1.2] ident=mail) by over.watchland.org with esmtp (Exim 3.12 #1 (Debian)) id 14vpAE-0004ey-00; Fri, 04 May 2001 19:39:10 -0400 Received: from damon by debian with local (Exim 3.12 #1 (Debian)) id 14vpJH-00040c-00; Fri, 04 May 2001 19:48:31 -0400 Date: Fri, 4 May 2001 19:48:31 -0400 From: Damon McGraw To: Havoc Pennington Cc: Cristian Tibirna , wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010504194831.A15323@watchland.org> References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hp@redhat.com on Fri, May 04, 2001 at 06:29:42PM -0400 Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification IIRC Windows provides only the "what's this" for the current application and then only if context help is available for the widget that you click on. This help is also available (in most apps) by pressing F1 when the widget has focus. Having it available for the whole screen would be a plus (that way you could get it for panel applets as well as full apps). But wouldn't it make more sense if the button (or whatever) to activate it wasn't in a app? Perhaps somewhere on the panel or something instead? Damon ++ 04/05/01 18:29 -0400 - Havoc Pennington: > > Cristian Tibirna writes: > > Isn't this in the new NET spec already? > > > > I don't believe so, as Elliot says. > > I'm thinking of a protocol to do it; either a simple one so you could > click ? on a window and get help for stuff inside that window > (relatively easy) or a more complex thing so you can get help anywhere > on the screen. I'm not sure which one Windows has, actually. > > Havoc > > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list From mrogers@cs.ucl.ac.uk Mon May 7 16:31:51 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from clustermail.minx.net.uk (node-1.minx.net.uk [212.85.249.131]) by mail.gnome.org (Postfix) with ESMTP id 61DDD2C865 for ; Mon, 7 May 2001 16:31:51 -0400 (EDT) Received: from [212.1.154.68] (helo=dexter) by clustermail.minx.net.uk with esmtp (Exim 3.22 #2) id 14wri8-0005JB-00; Mon, 07 May 2001 21:34:35 +0100 Received: from michael by dexter with local (Exim 3.12 #1 (Debian)) id 14wrQv-00005C-00; Mon, 07 May 2001 21:16:41 +0100 Date: Mon, 7 May 2001 21:16:41 +0100 To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010507211641.B253@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sasha_Vasko@osca.state.mo.us on Mon, May 07, 2001 at 02:30:19PM -0500 From: Michael Rogers Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, May 07, 2001 at 02:30:19PM -0500, Sasha_Vasko@osca.state.mo.us wrote: > What cursor feedback exactly are you talking about. Care to provide some > definition ? Or did I miss something ? Besides any cursor manipulations > by client apps are highly discouraged in X. I think the idea is this: When the user clicks on the "What's this?" button, the owner of the button (let's call it the help client) grabs the pointer. Whenever the pointer enters a new window, the help client sends a message to that window. The owner of the window can install a new cursor to indicate that help is available for that widget (similar to the way DnD targets can identify themselves). Old toolkits will not understand the message, so the cursor will not change, so the user will know that no help is available. When the pointer leaves the window, the help client sends another message so the old cursor can be reinstalled. (The client should reinstall the old cursor after a few seconds if no messages are received from the help client, in case the help client has crashed.) When the user clicks on a widget, the help client sends a message to the clicked window and releases the pointer. The clicked widget can show simple tooltip-style help, or launch a standalone help browser if necessary. Neither method involves much bloat. The client doesn't need its own help browser. It could check the value of some environment variable / X resource / GConf resource to find out which app to launch, but that's really outside the scope of the WM spec (although it should probably be standardised in another freedesktop document). Michael From julian.adams@gmx.net Wed May 9 04:17:47 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from cmailg7.svr.pol.co.uk (cmailg7.svr.pol.co.uk [195.92.195.177]) by mail.gnome.org (Postfix) with ESMTP id D43272BB23 for ; Wed, 9 May 2001 04:17:46 -0400 (EDT) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14xPAF-0008AM-00; Wed, 09 May 2001 09:17:43 +0100 Received: from modem-33.leopard-shark.dialup.pol.co.uk ([62.137.37.161] helo=babybel.at_home) by mail18.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14xPAD-0003pp-00; Wed, 09 May 2001 09:17:42 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Julian Adams Reply-To: julian.adams@gmx.net To: Havoc Pennington Subject: Re: Publish revised spec ? Date: Wed, 9 May 2001 09:17:25 +0100 X-Mailer: KMail [version 1.2] Cc: Owen Taylor , wm-spec-list@gnome.org References: <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <01050909172500.07084@babybel.at_home> Content-Transfer-Encoding: 8bit Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Friday 04 May 2001 14:29, Havoc Pennington wrote: > I think I already dumped it on the web page a week or so ago... hope > this doesn't upset anyone. Maybe we can do an announce, if the changes > are interesting enough. > > Havoc Added a change history for 1.1. The changes are very dull, but I did it for completeness (and so you can just scan the change history). Let's get this up on the web as 1.1. Diff below: cvs -z3 diff -u wm-spec.sgml Index: wm-spec.sgml =================================================================== RCS file: /home/freedesktop/wm-spec/wm-spec.sgml,v retrieving revision 1.11 diff -u -r1.11 wm-spec.sgml --- wm-spec.sgml 2001/04/22 10:14:49 1.11 +++ wm-spec.sgml 2001/05/09 02:51:04 @@ -1167,6 +1167,32 @@ Change history + Changes since 1.0 + + +Fix doctype, add author info, update data. + + +Change specification description wording to be more inclusive, and to reflect the joint nature of the specification. + + +Fix miscellaneous typographical, grammar and spelling errors. + + +Clarified _NET_SUPPORTED to include ALL atoms, not just the property names. + + +Various corrections to use of MUST and SHOULD. + + +Fix problem in _NET_WM_ICON where 'bytes' should have been 'cardinals' + + +Replaced ISO-8559-1 characters with entities. + + + + Changes since 1.0pre5 From Sasha_Vasko@osca.state.mo.us Wed May 9 09:59:39 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 2A4A82BF61 for ; Wed, 9 May 2001 09:59:39 -0400 (EDT) Subject: Re: "What's this" To: Sasha_Vasko@osca.state.mo.us, Michael Rogers Cc: wm-spec-list@gnome.org From: Sasha_Vasko@osca.state.mo.us Date: Wed, 9 May 2001 08:56:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/09/2001 08:56:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, May 07, 2001 at 02:30:19PM -0500, Sasha_Vasko@osca.state.mo.us wrote: > > What cursor feedback exactly are you talking about. Care to provide some > > definition ? Or did I miss something ? Besides any cursor manipulations > > by client apps are highly discouraged in X. > > I think the idea is this: > > When the user clicks on the "What's this?" button, the owner of the button > (let's call it the help client) grabs the pointer. Whenever the pointer > enters a new window, the help client sends a message to that window. The > owner of the window can install a new cursor to indicate that help is You cannot install new cursor since help client has an active grab on the pointer at the moment > available for that widget (similar to the way DnD targets can identify > themselves). Old toolkits will not understand the message, so the cursor > will not change, so the user will know that no help is available. When > the pointer leaves the window, the help client sends another message so > the old cursor can be reinstalled. (The client should reinstall the old > cursor after a few seconds if no messages are received from the help > client, in case the help client has crashed.) You cannot query what was the old cursor > When the user clicks on a widget, the help client sends a message to the > clicked window and releases the pointer. Actuall protocol used by XDND is much more complicated and includes complicated 2-way message exchange, and it does takes ownership of selection, but mostly for the purpose of avoiding possible situation where 2 DND operations will be attempted at the same time. Like I said before - "what's this" stuff could be done by simply utilizing XDND protocol with custom action, like _NET_XdndActionWhatsThis for example. > The clicked widget can show simple tooltip-style help, or launch a > standalone help browser if necessary. Neither method involves much > bloat. The client doesn't need its own help browser. It could check the > value of some environment variable / X resource / GConf resource to find > out which app to launch, but that's really outside the scope of the WM > spec (although it should probably be standardised in another freedesktop > document). yes it is outside of the scope of this specs. Still, just as a general idea, think about it: wouldnot that be nice if there was a single app that could have given you a help on each and every client/widget on the desktop in some standard view, no matter if the widget is from GTK or from KDE or other place ? Maybe not exactly a "Whats this" feature - sort of like man page browser only smart enough to query what text should be displayed from the client window by itself - with no user typing in a name to look up. > Michael Cheers Sasha Vasko From mrogers@cs.ucl.ac.uk Wed May 9 15:13:21 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from clustermail.minx.net.uk (node-3.minx.net.uk [212.85.249.133]) by mail.gnome.org (Postfix) with ESMTP id EA82C2DE3B for ; Wed, 9 May 2001 15:13:20 -0400 (EDT) Received: from [212.1.141.153] (helo=dexter) by clustermail.minx.net.uk with esmtp (Exim 3.22 #4) id 14xZRo-00038f-00 for wm-spec-list@gnome.org; Wed, 09 May 2001 20:16:34 +0100 Received: from michael by dexter with local (Exim 3.12 #1 (Debian)) id 14xZM7-00007O-00 for ; Wed, 09 May 2001 20:10:39 +0100 Date: Wed, 9 May 2001 20:10:39 +0100 To: wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010509201039.D252@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sasha_Vasko@osca.state.mo.us on Wed, May 09, 2001 at 08:56:29AM -0500 From: Michael Rogers Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Wed, May 09, 2001 at 08:56:29AM -0500, Sasha_Vasko@osca.state.mo.us wrote: > You cannot install new cursor since help client has an active grab on the > pointer at the moment Sorry, I didn't realise (although that makes sense now I think about it!). Maybe XDnD is the best way to do it then. > Still, just as a general idea, think about it: wouldnot that be nice if > there was a single app that could have given you a help on each and > every client/widget on the desktop in some standard view, no matter if > the widget is from GTK or from KDE or other place ? Maybe not exactly > a "Whats this" feature - sort of like man page browser only smart > enough to query what text should be displayed from the client window by > itself - with no user typing in a name to look up. But Gnome and KDE would create their own implementations so you would still have the problem of choosing which one to launch! :) We should provide a way for the user to choose which app will be used to display help, in a way that any desktop environment or WM can understand. The user gets the "standard view", and the DEs get to bitch about who provides the best help browser. :) One possibility is to use ~/.mime.types - the user can choose which app should handle the content type x-documentation/man, for example, and when an app wants to display a man page it can launch the program that's registered to handle that MIME type. You would have different MIME types for different types of documentation (x-documentation/info, x-documentation/html, x-documentation/plain), which might point to the same versatile help browser or to standalone viewers. Michael From julian.adams@gmx.net Fri May 4 05:45:10 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by mail.gnome.org (Postfix) with SMTP id 343B92CEBC for ; Fri, 4 May 2001 05:43:11 -0400 (EDT) Received: (qmail 31843 invoked by uid 0); 4 May 2001 09:43:09 -0000 Received: from unknown (HELO JADAMS.gmx.net) (212.74.3.86) by mail.gmx.net (mail09) with SMTP; 4 May 2001 09:43:09 -0000 Message-Id: <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> X-Sender: zaftig.freeserve.co.uk@pop.freeserve.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 04 May 2001 10:46:34 +0100 To: Owen Taylor From: julian adams Subject: Re: Publish revised spec ? Cc: wm-spec-list@gnome.org In-Reply-To: References: <01042216381500.00718@babybel.at_home> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification I'll write up the changes over the next week, and then we can put it out. julian At 19:55 23/04/2001, Owen Taylor wrote: >Julian Adams writes: > > > I've commited a minor revision to the spec in CVS, clarifying=20 > _NET_SUPPORTED as > > discussed before. (diff below) > > > > I think this version of the spec (mainly David Wheeler's corrections)=20 > should > > get put out as a release as there are essential clarifications and=20 > corrections > > (e.g. the icon format). > >For people's reference, I've appended the diff -u betwen 1.0 and the >current version, with annotations to point what ones are spelling/etc. >and what ones are significant. > >The Changes section at the end needs to be updated to reflect the >3 significant changes. > >I think putting out a new revision at this point should be fine, >assuming everyone agrees with these changes. > >Regards, > Owen > > > diff -u -r1.9 -r1.11 > --- wm-spec.sgml 2000/11/22 21:40:56 1.9 > +++ wm-spec.sgml 2001/04/22 10:14:49 1.11 > @@ -1,22 +1,36 @@ > - + ]> >
> - > + > + > + > + X Desktop Group > + > + > Extended Window Manager Hints > -5 November 2000 > - > +10 March 2001 > + > >Fix doctype, add author info, update data. > > > Introduction > > Version > > -This spec is version 1.0. > +This is version 1.1 of the Extended Window Manager Hints (EWMH) spec, > +updated 10 March 2001. > >Update version > > > > What is this spec? > > -This spec defines interactions between window managers, applications=20 > and the utilities that form part of a desktop environment. It builds on= =20 > the ICCCM [2], which defines wm/client interactions at a lower level. It= =20 > was born out of a need to replace the original Gnome WM specification,=20 > although this specification has been designed to be independent of any=20 > one desktop environment. > +This spec defines interactions between window managers, applications, > +and the utilities that form part of a desktop environment. It builds > +on the ICCCM [2], which defines WM (window manager) interactions at a > +lower level. The ICCCM does not provide ways to implement many > +features that modern desktop users expect. The GNOME and KDE desktop > +projects originally developed their own extensions to the ICCCM to > +support these features; this spec replaces those custom extensions > +with a standardized set of ICCCM additions that any desktop > +environment can adopt. > >Change wording to be more inclusive, and to reflect the joint nature >of the specification. > > > > > @@ -82,7 +96,7 @@ > > > Modality > -The Window Manager_TRANSIENT_FOR hint of the ICCCM allows=20 > clients to specify that a > +The Window Manager _TRANSIENT_FOR hint of the ICCCM allows=20 > clients to specify that a > >Fix missing space. > > toplevel window may be closed before the client finishes. A typical=20 > example > of a transient window is a dialog. Some dialogs can be open for a=20 > long time, > while the user continues to work in the main window. Other dialogs=20 > have to be > @@ -183,7 +197,7 @@ > > > Animated iconification > -Some Window Managers display some form of animation when=20 > (de-)iconfying a window. > +Some Window Managers display some form of animation when=20 > (de-)iconifying a window. > >Spelling fix. > > This may be a line drawing connecting the corners of the window with > the corners of the icon or the window may be opaquely moved and resized > on some trajectory joining the window location and the icon=20 > location. > @@ -249,8 +263,10 @@ > ]]> > > This property MUST be set by the Window Manager to indicate which hints= it > -supports. This assumes that backwards incompatible changes will not=20 > be made > -to the hints (without being renamed). > +supports. For example: considering _NET_WM_STATE > +both this atom and all supported states e.g. _NET_WM_STATE_MODAL, > +_NET_WM_STATE_STICKY, would be listed. This assumes that backwards > +incompatible changes will not be made to the hints (without being=20 > renamed). > >Change to include ALL atoms, not just the property names. > > > _NET_CLIENT_LIST > @@ -286,7 +302,7 @@ > The Window Manager is free to honor or reject this request. If request= =20 > is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of=20 > desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of=20 > desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and=20 > _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES=20 > property MAY remain unchanged. > > > -If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out= =20 > of the new range of of available desktops, then this MUST must be set to= =20 > the last available desktop from the new set. If number of desktops is=20 > shrinking then clients that are still present on desktops, that are out=20 > of the new range, MUST be moved to the very last desktop from the new=20 > set. For these _NET_WM_DESKTOP MUST be updated. > +If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out= =20 > of the new range of available desktops, then this MUST be set to the last= =20 > available desktop from the new set. If number of desktops is shrinking=20 > then clients that are still present on desktops, that are out of the new= =20 > range, MUST be moved to the very last desktop from the new set. For these= =20 > _NET_WM_DESKTOP MUST be updated. > >Remove excess 'of', 'must'. > > > > > @@ -577,7 +593,7 @@ > _NET_WM_WINDOW_TYPE, ATOM[]/32 > ]]> > > -This MUST be set by the Client before mapping, to a list of atoms=20 > indicating > +This SHOULD be set by the Client before mapping, to a list of atoms=20 > indicating > the functional type of the window. This property SHOULD be used by=20 > the window > manager in determining the decoration, stacking position and other=20 > behaviour > of the window. The Client SHOULD specify window types in order of=20 > preference > >Change MUST to SHOULD. > > @@ -757,7 +773,7 @@ > > > This is an array of 32bit packed CARDINAL ARGB with high byte being A,= low > -byte being B. First two bytes are width, height. Data is in rows,=20 > left to > +byte being B. First two cardinals are width, height. Data is in=20 > rows, left to > right and top to bottom. > > > >Fix problem where 'bytes' should have been 'cardinals' > > @@ -1062,10 +1078,10 @@ > > > > -[1] ICCCM Version 2.0, =A74.1.2.3 and =A74.1.5 > +[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 > > > -[2] ICCCM Version 2.0, =A74.2.3 > +[2] ICCCM Version 2.0, §4.2.3 > >Replace iso-8559-1 with entitities. From hp@redhat.com Fri May 4 09:27:31 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 6B5B12DBD3 for ; Fri, 4 May 2001 09:27:31 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44DTaw07396; Fri, 4 May 2001 09:29:36 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: julian adams Cc: Owen Taylor , wm-spec-list@gnome.org Subject: Re: Publish revised spec ? References: <01042216381500.00718@babybel.at_home> <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> From: Havoc Pennington Date: 04 May 2001 09:29:36 -0400 In-Reply-To: julian adams's message of "Fri, 04 May 2001 10:46:34 +0100" Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification julian adams writes: > I'll write up the changes over the next week, and then we can put it out. > I think I already dumped it on the web page a week or so ago... hope this doesn't upset anyone. Maybe we can do an announce, if the changes are interesting enough. Havoc From hp@redhat.com Fri May 4 12:52:19 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 069812E957 for ; Fri, 4 May 2001 12:52:16 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44GsQd27078; Fri, 4 May 2001 12:54:26 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: wm-spec-list@gnome.org Subject: "What's this" From: Havoc Pennington Date: 04 May 2001 12:54:25 -0400 Message-ID: Lines: 11 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Hi, Has anyone implemented or considered implementing the Windows feature where the frame has a ? on it, and you click that to enter "What's this" mode and can then get help on stuff in the window? (Or is it a global mode and you can get help on anything onscreen?) Seems like we could have a simple protocol enabling this. Havoc From tibirna@kde.org Fri May 4 13:12:23 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by mail.gnome.org (Postfix) with ESMTP id C51302DFB4 for ; Fri, 4 May 2001 13:11:29 -0400 (EDT) Received: from there ([64.229.234.15]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> for ; Fri, 4 May 2001 13:11:29 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Cristian Tibirna Organization: KDE To: wm-spec-list@gnome.org Subject: Re: "What's this" Date: Fri, 4 May 2001 13:12:02 -0400 X-Mailer: KMail [version 1.2.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Friday 04 May 2001 12:54, you wrote: > Hi, > > Has anyone implemented or considered implementing the Windows feature > where the frame has a ? on it, and you click that to enter "What's > this" mode and can then get help on stuff in the window? (Or is it a > global mode and you can get help on anything onscreen?) > KDE has it all over the place. You actually get help only for the widgets for which you write "what's this" information explicitely, in KDE. But I believe this could be implemented otherwise in other places. > Seems like we could have a simple protocol enabling this. Hmm? Isn't this in the new NET spec already? -- Cristian Tibirna .. tibirna@sympatico.ca PhD Student .. ctibirna@giref.ulaval.ca .. www.giref.ulaval.ca/~ctibirna KDE contact - Canada .. tibirna@kde.org .. www.kde.org From sopwith@redhat.com Fri May 4 15:14:08 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 73E892C934 for ; Fri, 4 May 2001 15:14:08 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f44JE8S03930 for ; Fri, 4 May 2001 15:14:08 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Fri, 4 May 2001 15:14:07 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Subject: Re: "What's this" In-Reply-To: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Fri, 4 May 2001, Cristian Tibirna wrote: > > Has anyone implemented or considered implementing the Windows feature > > where the frame has a ? on it, and you click that to enter "What's > > this" mode and can then get help on stuff in the window? (Or is it a > > global mode and you can get help on anything onscreen?) > > KDE has it all over the place. You actually get help only for the widgets for > which you write "what's this" information explicitely, in KDE. But I believe > this could be implemented otherwise in other places. > > > Seems like we could have a simple protocol enabling this. > > Hmm? > > Isn't this in the new NET spec already? KDE just uses the Qt hack that does it in one process only. Doing that is easy and irrelevant to this list. A reasonable requirement would be for a "what's this" solution to work inter-application, which would mean coming up with an X protocol to do it. I started looking at this for gnome-libs once - the way I was thinking of doing it was having cursor feedback similar to DnD to point out areas that help can be given for, plus a way to tell the clicked-on area to show its help, once it is clicked. -- Elliot These three lines are for sale at the rate of $50/month. From hp@redhat.com Fri May 4 18:28:30 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 11E322BBE4 for ; Fri, 4 May 2001 18:28:29 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44MTgq03942; Fri, 4 May 2001 18:29:42 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Cristian Tibirna Cc: wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> From: Havoc Pennington Date: 04 May 2001 18:29:42 -0400 In-Reply-To: Cristian Tibirna's message of "Fri, 4 May 2001 13:12:02 -0400" Message-ID: Lines: 13 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Cristian Tibirna writes: > Isn't this in the new NET spec already? > I don't believe so, as Elliot says. I'm thinking of a protocol to do it; either a simple one so you could click ? on a window and get help for stuff inside that window (relatively easy) or a more complex thing so you can get help anywhere on the screen. I'm not sure which one Windows has, actually. Havoc From hp@redhat.com Fri May 4 19:56:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 4110A2BB87 for ; Fri, 4 May 2001 19:56:13 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44NvbY14667; Fri, 4 May 2001 19:57:37 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Damon McGraw Cc: Cristian Tibirna , wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> <20010504194831.A15323@watchland.org> From: Havoc Pennington Date: 04 May 2001 19:57:37 -0400 In-Reply-To: Damon McGraw's message of "Fri, 4 May 2001 19:48:31 -0400" Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Damon McGraw writes: > > Having it available for the whole screen would be a plus (that way you > could get it for panel applets as well as full apps). But wouldn't it > make more sense if the button (or whatever) to activate it wasn't in a > app? Perhaps somewhere on the panel or something instead? > Seems likely that's not really an issue the protocol would need to address - there would be some way to say "enter whatsthis mode" and the window manager or panel or whatever could provide a button that did that. Havoc From l.lunak@sh.cvut.cz Sat May 5 05:11:16 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mail.gnome.org (Postfix) with ESMTP id AABCF2CDA1 for ; Sat, 5 May 2001 05:11:15 -0400 (EDT) Received: from stoupa.sh.cvut.cz (stoupa.sh.cvut.cz [147.32.127.196]) by service.sh.cvut.cz (8.9.3/SH) with ESMTP id LAA15174 for ; Sat, 5 May 2001 11:11:14 +0200 Received: from there (seli@seli.sh.cvut.cz [147.32.122.38]) by stoupa.sh.cvut.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id LAA01583 for ; Sat, 5 May 2001 11:11:14 +0200 Message-Id: <200105050911.LAA01583@stoupa.sh.cvut.cz> Content-Type: text/plain; charset="iso-8859-2" From: Lubos Lunak To: wm-spec-list@gnome.org Subject: Re: "What's this" Date: Sat, 5 May 2001 11:11:12 +0200 X-Mailer: KMail [version 1.2.1] References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Dne so 5. kv=ECten 2001 00:29 jste napsal(a): > Cristian Tibirna writes: > > Isn't this in the new NET spec already? > > I don't believe so, as Elliot says. > > I'm thinking of a protocol to do it; either a simple one so you could > click ? on a window and get help for stuff inside that window > (relatively easy) or a more complex thing so you can get help anywhere > on the screen. I'm not sure which one Windows has, actually. Win2k has 'what's this' only for the active window, the same way it's in= =20 KDE/Qt ( which is IMHO good enough ). > > Havoc > Lubos Lunak -- l.lunak@email.cz ; l.lunak@kde.org http://dforce.sh.cvut.cz/~seli From otaylor@redhat.com Sat May 5 10:30:14 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from fresnel.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 5F7C52E087 for ; Sat, 5 May 2001 10:30:14 -0400 (EDT) Received: by fresnel.labs.redhat.com (Postfix, from userid 2181) id DB90A241C6D; Sat, 5 May 2001 10:30:13 -0400 (EDT) To: wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> <200105050911.LAA01583@stoupa.sh.cvut.cz> From: Owen Taylor Date: 05 May 2001 10:30:13 -0400 In-Reply-To: Lubos Lunak's message of "Sat, 5 May 2001 11:11:12 +0200" Message-ID: Lines: 47 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Lubos Lunak writes: > Dne so 5. kv=ECten 2001 00:29 jste napsal(a): > > Cristian Tibirna writes: > > > Isn't this in the new NET spec already? > > > > I don't believe so, as Elliot says. > > > > I'm thinking of a protocol to do it; either a simple one so you could > > click ? on a window and get help for stuff inside that window > > (relatively easy) or a more complex thing so you can get help anywhere > > on the screen. I'm not sure which one Windows has, actually. >=20 > Win2k has 'what's this' only for the active window, the same way it's in= =20 > KDE/Qt ( which is IMHO good enough ). Considering that: - "What's this" needs to be activated at least from the window manager title bar. - "What's this" needs to work across embedded subwindows. I don't think you get any essential simplification in implementation from allowing it only in a single window. And I think it's easy to do better than Windows in this respect: - Provide "what's this" globally, and in particular on desktop features such as the taskbar and desktop icons. - Provide feedback during the "what's this operation". (Having to guess what has help, and then restart the operation is the thing I found most annoying trying out this feature in Windows.) (The simplest feedback is simply a yes/no indication as in DND.=20 This is easy to implement and easy to standardize. I suspect it's possible to do better than this, either by providing some visual clue as to what elements have help, or by displaying the help immediately on mouse-over; but I'm not sure that the extra complexity would be worth it.) Regards, Owen From M.Rogers@cs.ucl.ac.uk Sat May 5 11:34:23 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.gnome.org (Postfix) with SMTP id 415192E0AD for ; Sat, 5 May 2001 11:34:23 -0400 (EDT) Received: from moorgate.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 5 May 2001 16:34:19 +0100 To: wm-spec-list@gnome.org Subject: Re: "What's this" In-reply-to: Your message of "04 May 2001 19:57:37 EDT." Date: Sat, 05 May 2001 16:34:18 +0100 Message-ID: <892.989076858@cs.ucl.ac.uk> From: Michael ROGERS Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification >Seems likely that's not really an issue the protocol would need to >address - there would be some way to say "enter whatsthis mode" and >the window manager or panel or whatever could provide a button that >did that. How about this: When the help button is pressed, the help client (could be the WM or a panel applet) grabs the pointer and installs a ? cursor. When the user clicks on an item, the help client sends a client message to the clicked window and releases the pointer. Clients that don't understand the message will ignore it; clients that understand it can display help. This could be a top-level help window, or one of those popup explanations that Windows uses, which don't disappear until you click on something. (Grab the pointer and use redirect override on the tooltip window?) This mechanism could be tied into the existing KDE help system (Qt would detect the client messages and invoke the existing mechanism), so a panel applet or WM could trigger the context-sensitive help attached to KDE widgets. Michael From jg@pa.dec.com Sat May 5 22:05:16 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.gnome.org (Postfix) with ESMTP id 113442CA71 for ; Sat, 5 May 2001 22:05:16 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 44D031C81; Sat, 5 May 2001 21:05:15 -0500 (CDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E7DAFD37; Sat, 5 May 2001 21:05:14 -0500 (CDT) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 897AC42F; Sat, 5 May 2001 22:05:14 -0400 (EDT) Received: from src-mail.pa.dec.com (src-mail.pa.dec.com [16.4.16.35]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 00F6E5EA; Sat, 5 May 2001 22:05:13 -0400 (EDT) Received: by src-mail.pa.dec.com; id TAA09428; Sat, 5 May 2001 19:05:13 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Received: (from pachydrm@localhost) by pachyderm.pa.dec.com (8.11.1/8.11.1) id f4625DU497096; Sat, 5 May 2001 19:05:13 -0700 (PDT) Date: Sat, 5 May 2001 19:05:13 -0700 (PDT) Message-Id: <200105060205.f4625DU497096@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Elliot Lee Cc: wm-spec-list@gnome.org In-Reply-To: Subject: Re: "What's this" Mime-Version: 1.0 Content-Type: text/plain Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification All that is really needed is to decorate the widget windows with the class and instance data from the toolkit, and then one can have an external process do the display. We need that data for things like "Hands off X" to work, and doing it externally means that it can be done to almost any application, independent of the author, in a uniform fashion across toolkits. - Jim > Sender: wm-spec-list-admin@gnome.org > From: Elliot Lee > Date: Fri, 4 May 2001 15:14:07 -0400 (EDT) > To: > Subject: Re: "What's this" > ----- > On Fri, 4 May 2001, Cristian Tibirna wrote: > > > > Has anyone implemented or considered implementing the Windows feature > > > where the frame has a ? on it, and you click that to enter "What's > > > this" mode and can then get help on stuff in the window? (Or is it a > > > global mode and you can get help on anything onscreen?) > > > > KDE has it all over the place. You actually get help only for the widgets > for > > which you write "what's this" information explicitely, in KDE. But I believe > > this could be implemented otherwise in other places. > > > > > Seems like we could have a simple protocol enabling this. > > > > Hmm? > > > > Isn't this in the new NET spec already? > > KDE just uses the Qt hack that does it in one process only. Doing that is > easy and irrelevant to this list. A reasonable requirement would be for a > "what's this" solution to work inter-application, which would mean coming > up with an X protocol to do it. > > I started looking at this for gnome-libs once - the way I was thinking of > doing it was having cursor feedback similar to DnD to point out areas that > help can be given for, plus a way to tell the clicked-on area to show its > help, once it is clicked. > > -- Elliot > These three lines > are for sale > at the rate of $50/month. > > > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com From hp@redhat.com Sun May 6 01:28:10 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 33B1C2CE26 for ; Sun, 6 May 2001 01:28:10 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f465UFd15508; Sun, 6 May 2001 01:30:15 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: jg@pa.dec.com (Jim Gettys) Cc: Elliot Lee , wm-spec-list@gnome.org Subject: Re: "What's this" References: <200105060205.f4625DU497096@pachyderm.pa.dec.com> From: Havoc Pennington Date: 06 May 2001 01:30:15 -0400 In-Reply-To: jg@pa.dec.com's message of "Sat, 5 May 2001 19:05:13 -0700 (PDT)" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification jg@pa.dec.com (Jim Gettys) writes: > All that is really needed is to decorate the widget windows with > the class and instance data from the toolkit, and then one can > have an external process do the display. One problem with that is that we already have a bunch of widgets (or useful-to-communicate-with widget subportions such as sheet cells) that don't have an X window. > We need that data for things like "Hands off X" to work, > and doing it externally means that it can be done to almost any > application, independent of the author, in a uniform fashion > across toolkits. If "Hands off X" is speech recognition stuff, the general GTK plan here (for in-process) is the accessibility API Sun is contributing. Then there is some out-of-process protocol yet to be defined, and a GTK module would be loaded into apps which exported the data obtained from the accessibility API to an alternative/supplemental input/output mechanism living in another process. I think "what's this" is very simple; you just have some way of signaling that you're in "what's this" mode, toolkits highlight widgets with available help; and you send some sort of message to whatever window gets clicked on, and the toolkit pops up the help. App authors just call widget_set_whats_this() and the toolkit magically makes it work. Havoc From olivier.chapuis@free.fr Sun May 6 09:02:42 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by mail.gnome.org (Postfix) with ESMTP id A50FA2BE20 for ; Sun, 6 May 2001 09:02:41 -0400 (EDT) Received: from snoopy.parislyon (paris11-nas2-42-12.dial.proxad.net [212.27.42.12]) by postfix2-1.free.fr (Postfix) with ESMTP id 80AD7C0E9; Sun, 6 May 2001 15:02:39 +0200 (CEST) Received: from snoopy.parislyon (snoopy.parislyon [127.0.0.1]) by snoopy.parislyon (Postfix) with SMTP id B1020242ED; Sun, 6 May 2001 14:54:53 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Olivier Chapuis To: fvwm-announce@fvwm.org, wm-spec-list@gnome.org Subject: fvwm-ewmh-0.1 is released Date: Sun, 6 May 2001 14:54:52 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01050614545200.26369@snoopy.parislyon> Content-Transfer-Encoding: 8bit Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification I am glad to announce the first version of fvwm-ewmh. fvwm-ewmh is constituted by a module, FvwmNetHints, and a patch against the last FVWM beta version (a stable candidate): fvwm-2.3.32. With these FVWM can handle Extended Window Manager Hints from the freedesktop group. This allows, for example, to run FVWM with KDE version 2. This package is alpha, however, it works not so bad on my machine. I announce this release with the hope to get some feedback before releasing version 0.2 which will be released a few days after fvwm-2.4.0 (with no announce to this list). Home Page (Download, Installation, Running, FAQ): http://fvwm-ewmh.sourceforge.net/ Screen Shots: http://fvwm-ewmh.sourceforge.net/screenshots/ Regards, Olivier From Sasha_Vasko@osca.state.mo.us Mon May 7 12:16:56 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 26C0A2DBB2 for ; Mon, 7 May 2001 12:16:56 -0400 (EDT) Subject: Re: "What's this" To: wm-spec-list@gnome.org, Michael ROGERS From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 11:13:56 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 11:14:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > >Seems likely that's not really an issue the protocol would need to > >address - there would be some way to say "enter whatsthis mode" and > >the window manager or panel or whatever could provide a button that > >did that. > > How about this: > > When the help button is pressed, the help client (could be the WM or a > panel applet) grabs the pointer and installs a ? cursor. When the user > clicks on an item, the help client sends a client message to the clicked > window and releases the pointer. Clients that don't understand the > message will ignore it; clients that understand it can display help. Clients should not be bothered with displaying help, unless you want to bloat all of them with basically identical help rendering code. Much cleaner approach would be for single help app. It would query client about context of the mouse click ( basically send it message like: ) on which client should respond with meaningfull text data identifying what help should be displayed - something like . help app then goes and at all known to it locations for this particular information. In case client does not support/respond to thins protocol - then help app simply falls back to using res_name, res_class from client's hints, and goes looking for the man page for this client. X selections would be a good way to implement such a protocol. Compliant clients should acqure ownership of the selection on its top level window something like _NET_HELP. help app then sends them request, passing parameters along in its target property _NET_HELP_REQUEST, created on its own window. And client should respond to it, by placing click context description info into this target property. If client is not an owner of selection _NET_HELP or if it does not respond within reasonable timeout - help app goes on and displays help based on clients Class hints. Something along this lines. > This could be a top-level help window, or one of those popup > explanations that Windows uses, which don't disappear until you click on > something. (Grab the pointer and use redirect override on the tooltip > window?) > > This mechanism could be tied into the existing KDE help system (Qt would > detect the client messages and invoke the existing mechanism), so a > panel applet or WM could trigger the context-sensitive help attached to > KDE widgets. > > Michael > Regards Sasha Vasko From sopwith@redhat.com Mon May 7 12:37:02 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id D79E52CBBE for ; Mon, 7 May 2001 12:37:01 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Gav525322; Mon, 7 May 2001 12:36:57 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 12:36:57 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Jim Gettys Cc: Subject: Re: "What's this" In-Reply-To: <200105060205.f4625DU497096@pachyderm.pa.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Sat, 5 May 2001, Jim Gettys wrote: > All that is really needed is to decorate the widget windows with > the class and instance data from the toolkit, and then one can > have an external process do the display. This is not sufficient to meet the requirements I had in mind. The application whose help is being requested has to be asked to display the help, because it can display it in a manner that best fits the item in question. Also, this approach won't work for widgets without windows... (Not saying that that class/instance info does/doesn't need to be there, of course - if you want it there just file a gtk bug. :-) -- Elliot These three lines are for sale at the rate of $50/month. From sopwith@redhat.com Mon May 7 12:45:02 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 6E5322BAB1 for ; Mon, 7 May 2001 12:45:02 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Giua26941; Mon, 7 May 2001 12:44:56 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 12:44:56 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Cc: , Michael ROGERS Subject: Re: "What's this" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > Clients should not be bothered with displaying help, unless you want to > bloat all of them with basically identical help rendering code. Clients are the only pieces that know how to best display the help. If someone wants to implement the paperclip (whether you like it or not, that case needs to be possible), doing it in the client is the only sane way. If client wishes to use a standardized-help-display-mechanism to show the popup help, then it is entirely possible, but that's a separate problem to be solved - let's not complicate the problem further than it has to be. Right now the only thing to do is find out whether a client has help available for a widget (to provide cursor feedback) and ask the client to provide that help... So, I'm in rough agreement with Havoc on this one, -- Elliot These three lines are for sale at the rate of $50/month. From jg@pa.dec.com Mon May 7 13:20:11 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.gnome.org (Postfix) with ESMTP id 3B3E72BBE0 for ; Mon, 7 May 2001 13:20:11 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 83655CFF; Mon, 7 May 2001 12:20:10 -0500 (CDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4A9A3E18; Mon, 7 May 2001 12:20:10 -0500 (CDT) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id EB7F329B; Mon, 7 May 2001 10:20:09 -0700 (PDT) Received: from src-mail.pa.dec.com (src-mail.pa.dec.com [16.4.16.35]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id DCF0315A; Mon, 7 May 2001 10:20:09 -0700 (PDT) Received: by src-mail.pa.dec.com; id KAA17194; Mon, 7 May 2001 10:20:09 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Received: (from pachydrm@localhost) by pachyderm.pa.dec.com (8.11.1/8.11.1) id f47HK97280588; Mon, 7 May 2001 10:20:09 -0700 (PDT) Date: Mon, 7 May 2001 10:20:09 -0700 (PDT) Message-Id: <200105071720.f47HK97280588@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Elliot Lee Cc: Jim Gettys , wm-spec-list@gnome.org In-Reply-To: Subject: Re: "What's this" Mime-Version: 1.0 Content-Type: text/plain Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > From: Elliot Lee > Date: Mon, 7 May 2001 12:36:57 -0400 (EDT) > To: Jim Gettys > Cc: > Subject: Re: "What's this" > ----- > On Sat, 5 May 2001, Jim Gettys wrote: > > > All that is really needed is to decorate the widget windows with > > the class and instance data from the toolkit, and then one can > > have an external process do the display. > > This is not sufficient to meet the requirements I had in mind. The > application whose help is being requested has to be asked to display the > help, because it can display it in a manner that best fits the item in > question. Yes, but it would get 90%, and would allow for help on toolkits that don't do this at all. So how about this scheme, suitably modified to inform clients, so that they can provide help if need be to cover these cases. > > Also, this approach won't work for widgets without windows... > > (Not saying that that class/instance info does/doesn't need to be there, > of course - if you want it there just file a gtk bug. :-) OK, will do :-). Where is the bug reporting system? - Jim -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com From Sasha_Vasko@osca.state.mo.us Mon May 7 13:27:20 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 70E442BBE0 for ; Mon, 7 May 2001 13:27:20 -0400 (EDT) Subject: Re: "What's this" To: Elliot Lee Cc: From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 12:24:32 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 12:24:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > > > Clients should not be bothered with displaying help, unless you want to > > bloat all of them with basically identical help rendering code. > > Clients are the only pieces that know how to best display the help. If > someone wants to implement the paperclip (whether you like it or not, that > case needs to be possible), doing it in the client is the only sane way. While using proposed selection mechanism, it would be possible for client to respond with some special answer, indicating its desire to "Take over" help displaying. I would estimate, thou, that 95% of Unix/Linux/open source apps will not want to do that. It really is kinda stupid to write a man page, and then code huge piece of code into your application to display basically same information. I understand that this is different for BIG applications like Web Browsers/Word Processors, but we should not be thinking solely about those, and if there is a simple way of implementing generic algorithm, that automagically supports ALL unix applications, without changes required to most of those - we should go with it. Using huge library of man pages is a good thing (TM). > > If client wishes to use a standardized-help-display-mechanism to show the > popup help, then it is entirely possible, but that's a separate problem to > be solved - let's not complicate the problem further than it has to be. > Right now the only thing to do is find out whether a client has help > available for a widget (to provide cursor feedback) and ask the client to > provide that help... Selections mechanism is very simple to implement, and most of those BIG apps that needs it, should already have some selections management code, since things like clipboard are implemented this way. On the other hand standardizing some inferior ad-hoc solution is a nasty, way to go since it will provide a very limited solution (you don't have 2-way communications, so there is no way to find out if app has acknowledged request, and therefore you can't implement any fallback techniques ). And we'll need to live with it till the rest of our lives, and ppl will be pointing fingers, blaming us in very harsh words, and we'll be tearing our hair out, and there will not be a way back, etc. , etc., etc. Sooner or later some 2-way communications will have to be implemented, so why not do it right the first time. It's not like if we don't come up with something today - world collapses. > > So, I'm in rough agreement with Havoc on this one, > -- Elliot Regards Sasha Vasko From sopwith@redhat.com Mon May 7 13:37:20 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 081BF2E1BF for ; Mon, 7 May 2001 13:37:20 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Hb9404620; Mon, 7 May 2001 13:37:09 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 13:37:09 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Cc: Subject: Re: "What's this" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > I would estimate, thou, that 95% of Unix/Linux/open source apps will > not want to do that. It really is kinda stupid to write a man page Applications are free to share help system solutions, but they need to do it outside of this idea. Given that there are many other ways to use a help system beside "what's this" kind of help, and that the "what's this" help will need to be integrated into the other parts of the help system, it does not make sense to involve the help display part of things in this spec. This idea is not about specifying a common help system for displaying help, only about one particular method of requesting help that needs to be interoperable to benefit the user most. > On the other hand standardizing some inferior ad-hoc solution is a > nasty, way to go since it will provide a very limited solution (you > don't have 2-way communications, so there is no way to find out if app > has acknowledged request, and therefore you can't implement any > fallback techniques ). Cursor feedback was part of the requirements I gave. If an app doesn't participate in that, then you can do your fallback stuff. -- Elliot These three lines are for sale at the rate of $50/month. From hp@redhat.com Mon May 7 14:17:59 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 72FA92E249 for ; Mon, 7 May 2001 14:12:14 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f47IEAD22635; Mon, 7 May 2001 14:14:10 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org, Michael ROGERS Subject: Re: "What's this" References: From: Havoc Pennington Date: 07 May 2001 14:14:10 -0400 In-Reply-To: Sasha_Vasko@osca.state.mo.us's message of "Mon, 7 May 2001 11:13:56 -0500" Message-ID: Lines: 24 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Sasha_Vasko@osca.state.mo.us writes: > Clients should not be bothered with displaying help, unless you want to > bloat all of them with basically identical help rendering code. The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. There are two problems with the approach you mention: - people want something higher-level than text in the help, e.g. a simple HTML-like subset with links, etc. - help needs to work within a client even if no "help manager" app is running; i.e. the client needs a fallback implementation in any case, it can't rely on a desktop runtime environment being active. So you can't eliminate the toolkit code in any case. (And Qt already has this code, anyhow.) man pages certainly aren't the kind of help we're discussing here; what's this help is just a paragraph on the specific widget that's been clicked. Sort of longer tooltips, maybe with embedded links to the full documentation for the app. Havoc From Sasha_Vasko@osca.state.mo.us Mon May 7 15:26:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 7E7E72DB6D for ; Mon, 7 May 2001 15:26:13 -0400 (EDT) Subject: Re: "What's this" To: Havoc Pennington Cc: wm-spec-list@gnome.org, Michael ROGERS From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 14:23:25 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:23:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > Sasha_Vasko@osca.state.mo.us writes: > > Clients should not be bothered with displaying help, unless you want to > > bloat all of them with basically identical help rendering code. > > The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. > wait a sec. Are we disscussing "what's this" feature applicable only to toolkits ? If so then I retract all my proposals. I thought that you wanted to be able to get help not only on toolkit windows but universally on any object on the desktop. I don't think that any sane window manager is going to implement its own hyperlinked help browser - the best you can count on is popping up mozilla or term with man page/faqs displayed in it. What that brings you to is that user may get all kinds of help systems from different desktop objects - from GTK apps - one, from QT apps - another and completely different from something else, and nothing at all from most other things. All of those things will have different look and feel, which is not nice. If you really want to implement global help system, you have to think about signle app, that can display help for both GTK/Qt as well as the rest of the world. If all you need is internal toolkit help browser - then why bother with standard? I don't think it will make any sense at all for window manager to implement "What's it" button which will work only in GTK/QT, and will not work correctly even on its own interface elements. Besides do you actually see all the apps linked as dynamically only from now onwards? Cos if you link it statically - you do get bloat issue. > There are two problems with the approach you mention: > > - people want something higher-level than text in the help, > e.g. a simple HTML-like subset with links, etc. It's not difficult to implement help browser that would intelligently distinguish between help available in HTML, XML, man pages or any other format. And in fact man pages could be displayed as a hyperlinked text, and are very nice in that way. > > - help needs to work within a client even if no "help manager" app is > running; i.e. the client needs a fallback implementation in any > case, it can't rely on a desktop runtime environment being active. > So you can't eliminate the toolkit code in any case. (And Qt > already has this code, anyhow.) Well, if globally active help system is not running - then this entire disscussion is not applicable anyways - each client will have to rely upon itself entirely. The interesting implication is that you do not really need window manager involvement at all - you click on desktop icon/menu item-> that will launch help app -> help app grabs pointer and waits for a click -> then it traverses window tree in order to find out any parent window with wm hints set. etc. etc. etc. > man pages certainly aren't the kind of help we're discussing here; > what's this help is just a paragraph on the specific widget that's > been clicked. Sort of longer tooltips, maybe with embedded links to > the full documentation for the app. It still has to be a paragraph out of complete set of docs - and as such I do not see much difficulty in displaying particular topic out of HTML file, or even a man page for that matter. Anyways I just proposed the way it could be implemented using standard X approach. I don't seem to see any other alternative proposals, except for Michael Roger's one , which is basically the same as what I proposed, only with messages instead of selection( which is not good for 2-way communications). So what is this exactly we are arguing about ? What is your alternative? > > Havoc From Sasha_Vasko@osca.state.mo.us Mon May 7 15:33:11 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id D866D2CE3D for ; Mon, 7 May 2001 15:33:08 -0400 (EDT) Subject: Re: "What's this" To: , Elliot Lee Cc: From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 14:30:19 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:30:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > > > I would estimate, thou, that 95% of Unix/Linux/open source apps will > > not want to do that. It really is kinda stupid to write a man page > > Applications are free to share help system solutions, but they need to do > it outside of this idea. Given that there are many other ways to use a > help system beside "what's this" kind of help, and that the "what's this" > help will need to be integrated into the other parts of the help system, > it does not make sense to involve the help display part of things in this > spec. This idea is not about specifying a common help system for > displaying help, only about one particular method of requesting help that > needs to be interoperable to benefit the user most. X Selections is the most standrad and interoperable way to implement such things. It has been specifically designed for this purpose. > > On the other hand standardizing some inferior ad-hoc solution is a > > nasty, way to go since it will provide a very limited solution (you > > don't have 2-way communications, so there is no way to find out if app > > has acknowledged request, and therefore you can't implement any > > fallback techniques ). > > Cursor feedback was part of the requirements I gave. If an app doesn't > participate in that, then you can do your fallback stuff. What cursor feedback exactly are you talking about. Care to provide some definition ? Or did I miss something ? Besides any cursor manipulations by client apps are highly discouraged in X. > -- Elliot From hp@redhat.com Mon May 7 15:50:46 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 5EE832CB80 for ; Mon, 7 May 2001 15:50:46 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f47Jqf908069; Mon, 7 May 2001 15:52:41 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org, Michael ROGERS Subject: Re: "What's this" References: From: Havoc Pennington Date: 07 May 2001 15:52:41 -0400 In-Reply-To: Sasha_Vasko@osca.state.mo.us's message of "Mon, 7 May 2001 14:23:25 -0500" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Sasha_Vasko@osca.state.mo.us writes: > > So what is this exactly we are arguing about ? What is your alternative? > My original thought on this was just a spec for putting the ? button in the WM decoration. That is, the client would set a hint "I support what's this" and the WM would send a message if the user clicked the what's this button. But the actual help is just within the app. The more ambitious idea is that clicking what's this works for the entire desktop. This would require a protocol similar to drag-and-drop, which would normally be implemented in toolkits (since the only people who no longer use toolkits are people writing window managers, pretty much, and even the newer WMs use a toolkit whenever they want to display dialogs and such). This would work similar to drag-and-drop; a client would enter what's this mode (grab pointer, change cursor); somehow notify other clients that the mode was entered so they could highlight targets; as you moved the pointer around, it would change to indicate whether you were on a target; when you then clicked on a target, the target would receive some sort of message and reply back to the whatsthis-mode owner app that it should release the grab and leave the mode. There is a problem with inconsistency between toolkits, but this same problem exists for all aspects of toolkit look-and-feel, and it can be solved via theme coordination in the same way we'll solve e.g. button appearance. Havoc From raster@asterman.com Mon May 7 15:54:37 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from asterman.com (nat-hdqt.valinux.com [198.186.202.17]) by mail.gnome.org (Postfix) with ESMTP id 86D802CB80 for ; Mon, 7 May 2001 15:54:36 -0400 (EDT) Received: (from raster@localhost) by asterman.com (8.11.0/8.11.0) id f47Iuw925915; Mon, 7 May 2001 11:56:58 -0700 Message-Id: <200105071856.f47Iuw925915@asterman.com> Date: Mon, 7 May 2001 11:56:58 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: "What's this" To: Sasha_Vasko@osca.state.mo.us Cc: hp@redhat.com, wm-spec-list@gnome.org, M.Rogers@cs.ucl.ac.uk In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On 7 May, Sasha_Vasko@osca.state.mo.us scribbled: > > > Sasha_Vasko@osca.state.mo.us writes: > > > Clients should not be bothered with displaying help, unless you want to > > > bloat all of them with basically identical help rendering code. > > > > The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. > > > > wait a sec. Are we disscussing "what's this" feature applicable only to > toolkits ? If so then I retract all my proposals. > > I thought that you wanted to be able to get help not only on toolkit > windows > but universally on any object on the desktop. I don't think that any > sane window manager is going to implement its own hyperlinked help I'm not averse to doing it... :) it's kinda fun.. alreayd implimented one for E16 (dox) because i just wanst willing to wait 10 secons for netscape to pop up with help info in it for some simple help docs with inline diagrams and links within the doc... :) the wm doesnt have to actually impliment the cod if you dont want to.. it coudl pass it off to a helper app installed and exec it passing the info along... > browser - the best you can count on is popping up mozilla or term with > man page/faqs displayed in it. What that brings you to is that user may get > all kinds of help systems from different desktop objects - from GTK apps - > one, > from QT apps - another and completely different from something else, > and nothing at all from most other things. All of those things will > have different look and feel, which is not nice. If you really want to > implement global help system, you have to think about signle app, that can > display help for both GTK/Qt as well as the rest of the world. unless you write it - it will never happen. both camps will do (and alreayd have done) their own. you can do one - but neither side will use it. welcome to the world fo warring desktops. we can standardize but each mob have their own implimentation of those standards - and you either pick one side or the other or you get a mish-mash of them. you're call as a user. personally i'm happy to just impliment my own stuff for myself and be done with it :) saves me having to choose choose a job .. choose a family.. choose a fucking big television.. choose life. :) > If all you need is internal toolkit help browser - then why bother with > standard? I don't think it will make any sense at all for window manager > to implement "What's it" button which will work only in GTK/QT, and > will not work correctly even on its own interface elements. > > Besides do you actually see all the apps linked as dynamically only > from now onwards? Cos if you link it statically - you do get bloat issue. -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com VA Linux Systems raster@deephackmode.org Mobile Phone: +1 408 887 3163 Work Phone: +1 510 687 7069 From Sasha_Vasko@osca.state.mo.us Mon May 7 17:18:17 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id A78A32E318 for ; Mon, 7 May 2001 17:18:17 -0400 (EDT) Subject: Re: "What's this" To: wm-spec-list@gnome.org From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 16:15:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 04:15:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > Sasha_Vasko@osca.state.mo.us writes: > > > > So what is this exactly we are arguing about ? What is your alternative? > > > > My original thought on this was just a spec for putting the ? button > in the WM decoration. That is, the client would set a hint "I support > what's this" and the WM would send a message if the user clicked the > what's this button. But the actual help is just within the app. Hmm, is thtat really all that simple? I mean upon receiving such a message app would have to grab pointer. But pointer may still be on titlebar - which is window Managers area of resposibility. Just as well user mayhave gone and quickly clicked somewhere else, while "What's this" message was traveling from window manager to client app. > The more ambitious idea is that clicking what's this works for the > entire desktop. This would require a protocol similar to > drag-and-drop, which would normally be implemented in toolkits (since > the only people who no longer use toolkits are people writing window > managers, pretty much, and even the newer WMs use a toolkit whenever > they want to display dialogs and such). > > This would work similar to drag-and-drop; a client would enter what's > this mode (grab pointer, change cursor); somehow notify other clients > that the mode was entered so they could highlight targets; as you > moved the pointer around, it would change to indicate whether you were > on a target; when you then clicked on a target, the target would > receive some sort of message and reply back to the whatsthis-mode > owner app that it should release the grab and leave the mode. well, that could be achieved by using same XDND with some custom Action type (AFAIK). BTW XDND does uses selection :) > There is a problem with inconsistency between toolkits, but this same > problem exists for all aspects of toolkit look-and-feel, and it can be > solved via theme coordination in the same way we'll solve e.g. button > appearance. Heh, still idea of linking whole HTML widget into tiny clock app for the sole purpose of being able to display some short info strikes me as monstrous. > > Havoc > Sasha Vasko From damon@watchland.org Fri May 4 19:33:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from over.watchland.org (WATCHLAND.ORG [208.138.115.93]) by mail.gnome.org (Postfix) with ESMTP id 6B8112BB87 for ; Fri, 4 May 2001 19:33:13 -0400 (EDT) Received: from debian ([192.168.1.2] ident=mail) by over.watchland.org with esmtp (Exim 3.12 #1 (Debian)) id 14vpAE-0004ey-00; Fri, 04 May 2001 19:39:10 -0400 Received: from damon by debian with local (Exim 3.12 #1 (Debian)) id 14vpJH-00040c-00; Fri, 04 May 2001 19:48:31 -0400 Date: Fri, 4 May 2001 19:48:31 -0400 From: Damon McGraw To: Havoc Pennington Cc: Cristian Tibirna , wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010504194831.A15323@watchland.org> References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hp@redhat.com on Fri, May 04, 2001 at 06:29:42PM -0400 Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification IIRC Windows provides only the "what's this" for the current application and then only if context help is available for the widget that you click on. This help is also available (in most apps) by pressing F1 when the widget has focus. Having it available for the whole screen would be a plus (that way you could get it for panel applets as well as full apps). But wouldn't it make more sense if the button (or whatever) to activate it wasn't in a app? Perhaps somewhere on the panel or something instead? Damon ++ 04/05/01 18:29 -0400 - Havoc Pennington: > > Cristian Tibirna writes: > > Isn't this in the new NET spec already? > > > > I don't believe so, as Elliot says. > > I'm thinking of a protocol to do it; either a simple one so you could > click ? on a window and get help for stuff inside that window > (relatively easy) or a more complex thing so you can get help anywhere > on the screen. I'm not sure which one Windows has, actually. > > Havoc > > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list From mrogers@cs.ucl.ac.uk Mon May 7 16:31:51 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from clustermail.minx.net.uk (node-1.minx.net.uk [212.85.249.131]) by mail.gnome.org (Postfix) with ESMTP id 61DDD2C865 for ; Mon, 7 May 2001 16:31:51 -0400 (EDT) Received: from [212.1.154.68] (helo=dexter) by clustermail.minx.net.uk with esmtp (Exim 3.22 #2) id 14wri8-0005JB-00; Mon, 07 May 2001 21:34:35 +0100 Received: from michael by dexter with local (Exim 3.12 #1 (Debian)) id 14wrQv-00005C-00; Mon, 07 May 2001 21:16:41 +0100 Date: Mon, 7 May 2001 21:16:41 +0100 To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010507211641.B253@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sasha_Vasko@osca.state.mo.us on Mon, May 07, 2001 at 02:30:19PM -0500 From: Michael Rogers Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, May 07, 2001 at 02:30:19PM -0500, Sasha_Vasko@osca.state.mo.us wrote: > What cursor feedback exactly are you talking about. Care to provide some > definition ? Or did I miss something ? Besides any cursor manipulations > by client apps are highly discouraged in X. I think the idea is this: When the user clicks on the "What's this?" button, the owner of the button (let's call it the help client) grabs the pointer. Whenever the pointer enters a new window, the help client sends a message to that window. The owner of the window can install a new cursor to indicate that help is available for that widget (similar to the way DnD targets can identify themselves). Old toolkits will not understand the message, so the cursor will not change, so the user will know that no help is available. When the pointer leaves the window, the help client sends another message so the old cursor can be reinstalled. (The client should reinstall the old cursor after a few seconds if no messages are received from the help client, in case the help client has crashed.) When the user clicks on a widget, the help client sends a message to the clicked window and releases the pointer. The clicked widget can show simple tooltip-style help, or launch a standalone help browser if necessary. Neither method involves much bloat. The client doesn't need its own help browser. It could check the value of some environment variable / X resource / GConf resource to find out which app to launch, but that's really outside the scope of the WM spec (although it should probably be standardised in another freedesktop document). Michael From julian.adams@gmx.net Wed May 9 04:17:47 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from cmailg7.svr.pol.co.uk (cmailg7.svr.pol.co.uk [195.92.195.177]) by mail.gnome.org (Postfix) with ESMTP id D43272BB23 for ; Wed, 9 May 2001 04:17:46 -0400 (EDT) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14xPAF-0008AM-00; Wed, 09 May 2001 09:17:43 +0100 Received: from modem-33.leopard-shark.dialup.pol.co.uk ([62.137.37.161] helo=babybel.at_home) by mail18.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14xPAD-0003pp-00; Wed, 09 May 2001 09:17:42 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Julian Adams Reply-To: julian.adams@gmx.net To: Havoc Pennington Subject: Re: Publish revised spec ? Date: Wed, 9 May 2001 09:17:25 +0100 X-Mailer: KMail [version 1.2] Cc: Owen Taylor , wm-spec-list@gnome.org References: <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <01050909172500.07084@babybel.at_home> Content-Transfer-Encoding: 8bit Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Friday 04 May 2001 14:29, Havoc Pennington wrote: > I think I already dumped it on the web page a week or so ago... hope > this doesn't upset anyone. Maybe we can do an announce, if the changes > are interesting enough. > > Havoc Added a change history for 1.1. The changes are very dull, but I did it for completeness (and so you can just scan the change history). Let's get this up on the web as 1.1. Diff below: cvs -z3 diff -u wm-spec.sgml Index: wm-spec.sgml =================================================================== RCS file: /home/freedesktop/wm-spec/wm-spec.sgml,v retrieving revision 1.11 diff -u -r1.11 wm-spec.sgml --- wm-spec.sgml 2001/04/22 10:14:49 1.11 +++ wm-spec.sgml 2001/05/09 02:51:04 @@ -1167,6 +1167,32 @@ Change history + Changes since 1.0 + + +Fix doctype, add author info, update data. + + +Change specification description wording to be more inclusive, and to reflect the joint nature of the specification. + + +Fix miscellaneous typographical, grammar and spelling errors. + + +Clarified _NET_SUPPORTED to include ALL atoms, not just the property names. + + +Various corrections to use of MUST and SHOULD. + + +Fix problem in _NET_WM_ICON where 'bytes' should have been 'cardinals' + + +Replaced ISO-8559-1 characters with entities. + + + + Changes since 1.0pre5 From Sasha_Vasko@osca.state.mo.us Wed May 9 09:59:39 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 2A4A82BF61 for ; Wed, 9 May 2001 09:59:39 -0400 (EDT) Subject: Re: "What's this" To: Sasha_Vasko@osca.state.mo.us, Michael Rogers Cc: wm-spec-list@gnome.org From: Sasha_Vasko@osca.state.mo.us Date: Wed, 9 May 2001 08:56:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/09/2001 08:56:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, May 07, 2001 at 02:30:19PM -0500, Sasha_Vasko@osca.state.mo.us wrote: > > What cursor feedback exactly are you talking about. Care to provide some > > definition ? Or did I miss something ? Besides any cursor manipulations > > by client apps are highly discouraged in X. > > I think the idea is this: > > When the user clicks on the "What's this?" button, the owner of the button > (let's call it the help client) grabs the pointer. Whenever the pointer > enters a new window, the help client sends a message to that window. The > owner of the window can install a new cursor to indicate that help is You cannot install new cursor since help client has an active grab on the pointer at the moment > available for that widget (similar to the way DnD targets can identify > themselves). Old toolkits will not understand the message, so the cursor > will not change, so the user will know that no help is available. When > the pointer leaves the window, the help client sends another message so > the old cursor can be reinstalled. (The client should reinstall the old > cursor after a few seconds if no messages are received from the help > client, in case the help client has crashed.) You cannot query what was the old cursor > When the user clicks on a widget, the help client sends a message to the > clicked window and releases the pointer. Actuall protocol used by XDND is much more complicated and includes complicated 2-way message exchange, and it does takes ownership of selection, but mostly for the purpose of avoiding possible situation where 2 DND operations will be attempted at the same time. Like I said before - "what's this" stuff could be done by simply utilizing XDND protocol with custom action, like _NET_XdndActionWhatsThis for example. > The clicked widget can show simple tooltip-style help, or launch a > standalone help browser if necessary. Neither method involves much > bloat. The client doesn't need its own help browser. It could check the > value of some environment variable / X resource / GConf resource to find > out which app to launch, but that's really outside the scope of the WM > spec (although it should probably be standardised in another freedesktop > document). yes it is outside of the scope of this specs. Still, just as a general idea, think about it: wouldnot that be nice if there was a single app that could have given you a help on each and every client/widget on the desktop in some standard view, no matter if the widget is from GTK or from KDE or other place ? Maybe not exactly a "Whats this" feature - sort of like man page browser only smart enough to query what text should be displayed from the client window by itself - with no user typing in a name to look up. > Michael Cheers Sasha Vasko From mrogers@cs.ucl.ac.uk Wed May 9 15:13:21 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from clustermail.minx.net.uk (node-3.minx.net.uk [212.85.249.133]) by mail.gnome.org (Postfix) with ESMTP id EA82C2DE3B for ; Wed, 9 May 2001 15:13:20 -0400 (EDT) Received: from [212.1.141.153] (helo=dexter) by clustermail.minx.net.uk with esmtp (Exim 3.22 #4) id 14xZRo-00038f-00 for wm-spec-list@gnome.org; Wed, 09 May 2001 20:16:34 +0100 Received: from michael by dexter with local (Exim 3.12 #1 (Debian)) id 14xZM7-00007O-00 for ; Wed, 09 May 2001 20:10:39 +0100 Date: Wed, 9 May 2001 20:10:39 +0100 To: wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010509201039.D252@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sasha_Vasko@osca.state.mo.us on Wed, May 09, 2001 at 08:56:29AM -0500 From: Michael Rogers Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Wed, May 09, 2001 at 08:56:29AM -0500, Sasha_Vasko@osca.state.mo.us wrote: > You cannot install new cursor since help client has an active grab on the > pointer at the moment Sorry, I didn't realise (although that makes sense now I think about it!). Maybe XDnD is the best way to do it then. > Still, just as a general idea, think about it: wouldnot that be nice if > there was a single app that could have given you a help on each and > every client/widget on the desktop in some standard view, no matter if > the widget is from GTK or from KDE or other place ? Maybe not exactly > a "Whats this" feature - sort of like man page browser only smart > enough to query what text should be displayed from the client window by > itself - with no user typing in a name to look up. But Gnome and KDE would create their own implementations so you would still have the problem of choosing which one to launch! :) We should provide a way for the user to choose which app will be used to display help, in a way that any desktop environment or WM can understand. The user gets the "standard view", and the DEs get to bitch about who provides the best help browser. :) One possibility is to use ~/.mime.types - the user can choose which app should handle the content type x-documentation/man, for example, and when an app wants to display a man page it can launch the program that's registered to handle that MIME type. You would have different MIME types for different types of documentation (x-documentation/info, x-documentation/html, x-documentation/plain), which might point to the same versatile help browser or to standalone viewers. Michael From julian.adams@gmx.net Fri May 4 05:45:10 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by mail.gnome.org (Postfix) with SMTP id 343B92CEBC for ; Fri, 4 May 2001 05:43:11 -0400 (EDT) Received: (qmail 31843 invoked by uid 0); 4 May 2001 09:43:09 -0000 Received: from unknown (HELO JADAMS.gmx.net) (212.74.3.86) by mail.gmx.net (mail09) with SMTP; 4 May 2001 09:43:09 -0000 Message-Id: <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> X-Sender: zaftig.freeserve.co.uk@pop.freeserve.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 04 May 2001 10:46:34 +0100 To: Owen Taylor From: julian adams Subject: Re: Publish revised spec ? Cc: wm-spec-list@gnome.org In-Reply-To: References: <01042216381500.00718@babybel.at_home> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification I'll write up the changes over the next week, and then we can put it out. julian At 19:55 23/04/2001, Owen Taylor wrote: >Julian Adams writes: > > > I've commited a minor revision to the spec in CVS, clarifying=20 > _NET_SUPPORTED as > > discussed before. (diff below) > > > > I think this version of the spec (mainly David Wheeler's corrections)=20 > should > > get put out as a release as there are essential clarifications and=20 > corrections > > (e.g. the icon format). > >For people's reference, I've appended the diff -u betwen 1.0 and the >current version, with annotations to point what ones are spelling/etc. >and what ones are significant. > >The Changes section at the end needs to be updated to reflect the >3 significant changes. > >I think putting out a new revision at this point should be fine, >assuming everyone agrees with these changes. > >Regards, > Owen > > > diff -u -r1.9 -r1.11 > --- wm-spec.sgml 2000/11/22 21:40:56 1.9 > +++ wm-spec.sgml 2001/04/22 10:14:49 1.11 > @@ -1,22 +1,36 @@ > - + ]> >
> - > + > + > + > + X Desktop Group > + > + > Extended Window Manager Hints > -5 November 2000 > - > +10 March 2001 > + > >Fix doctype, add author info, update data. > > > Introduction > > Version > > -This spec is version 1.0. > +This is version 1.1 of the Extended Window Manager Hints (EWMH) spec, > +updated 10 March 2001. > >Update version > > > > What is this spec? > > -This spec defines interactions between window managers, applications=20 > and the utilities that form part of a desktop environment. It builds on= =20 > the ICCCM [2], which defines wm/client interactions at a lower level. It= =20 > was born out of a need to replace the original Gnome WM specification,=20 > although this specification has been designed to be independent of any=20 > one desktop environment. > +This spec defines interactions between window managers, applications, > +and the utilities that form part of a desktop environment. It builds > +on the ICCCM [2], which defines WM (window manager) interactions at a > +lower level. The ICCCM does not provide ways to implement many > +features that modern desktop users expect. The GNOME and KDE desktop > +projects originally developed their own extensions to the ICCCM to > +support these features; this spec replaces those custom extensions > +with a standardized set of ICCCM additions that any desktop > +environment can adopt. > >Change wording to be more inclusive, and to reflect the joint nature >of the specification. > > > > > @@ -82,7 +96,7 @@ > > > Modality > -The Window Manager_TRANSIENT_FOR hint of the ICCCM allows=20 > clients to specify that a > +The Window Manager _TRANSIENT_FOR hint of the ICCCM allows=20 > clients to specify that a > >Fix missing space. > > toplevel window may be closed before the client finishes. A typical=20 > example > of a transient window is a dialog. Some dialogs can be open for a=20 > long time, > while the user continues to work in the main window. Other dialogs=20 > have to be > @@ -183,7 +197,7 @@ > > > Animated iconification > -Some Window Managers display some form of animation when=20 > (de-)iconfying a window. > +Some Window Managers display some form of animation when=20 > (de-)iconifying a window. > >Spelling fix. > > This may be a line drawing connecting the corners of the window with > the corners of the icon or the window may be opaquely moved and resized > on some trajectory joining the window location and the icon=20 > location. > @@ -249,8 +263,10 @@ > ]]> > > This property MUST be set by the Window Manager to indicate which hints= it > -supports. This assumes that backwards incompatible changes will not=20 > be made > -to the hints (without being renamed). > +supports. For example: considering _NET_WM_STATE > +both this atom and all supported states e.g. _NET_WM_STATE_MODAL, > +_NET_WM_STATE_STICKY, would be listed. This assumes that backwards > +incompatible changes will not be made to the hints (without being=20 > renamed). > >Change to include ALL atoms, not just the property names. > > > _NET_CLIENT_LIST > @@ -286,7 +302,7 @@ > The Window Manager is free to honor or reject this request. If request= =20 > is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of=20 > desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of=20 > desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and=20 > _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES=20 > property MAY remain unchanged. > > > -If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out= =20 > of the new range of of available desktops, then this MUST must be set to= =20 > the last available desktop from the new set. If number of desktops is=20 > shrinking then clients that are still present on desktops, that are out=20 > of the new range, MUST be moved to the very last desktop from the new=20 > set. For these _NET_WM_DESKTOP MUST be updated. > +If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out= =20 > of the new range of available desktops, then this MUST be set to the last= =20 > available desktop from the new set. If number of desktops is shrinking=20 > then clients that are still present on desktops, that are out of the new= =20 > range, MUST be moved to the very last desktop from the new set. For these= =20 > _NET_WM_DESKTOP MUST be updated. > >Remove excess 'of', 'must'. > > > > > @@ -577,7 +593,7 @@ > _NET_WM_WINDOW_TYPE, ATOM[]/32 > ]]> > > -This MUST be set by the Client before mapping, to a list of atoms=20 > indicating > +This SHOULD be set by the Client before mapping, to a list of atoms=20 > indicating > the functional type of the window. This property SHOULD be used by=20 > the window > manager in determining the decoration, stacking position and other=20 > behaviour > of the window. The Client SHOULD specify window types in order of=20 > preference > >Change MUST to SHOULD. > > @@ -757,7 +773,7 @@ > > > This is an array of 32bit packed CARDINAL ARGB with high byte being A,= low > -byte being B. First two bytes are width, height. Data is in rows,=20 > left to > +byte being B. First two cardinals are width, height. Data is in=20 > rows, left to > right and top to bottom. > > > >Fix problem where 'bytes' should have been 'cardinals' > > @@ -1062,10 +1078,10 @@ > > > > -[1] ICCCM Version 2.0, =A74.1.2.3 and =A74.1.5 > +[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 > > > -[2] ICCCM Version 2.0, =A74.2.3 > +[2] ICCCM Version 2.0, §4.2.3 > >Replace iso-8559-1 with entitities. From hp@redhat.com Fri May 4 09:27:31 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 6B5B12DBD3 for ; Fri, 4 May 2001 09:27:31 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44DTaw07396; Fri, 4 May 2001 09:29:36 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: julian adams Cc: Owen Taylor , wm-spec-list@gnome.org Subject: Re: Publish revised spec ? References: <01042216381500.00718@babybel.at_home> <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> From: Havoc Pennington Date: 04 May 2001 09:29:36 -0400 In-Reply-To: julian adams's message of "Fri, 04 May 2001 10:46:34 +0100" Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification julian adams writes: > I'll write up the changes over the next week, and then we can put it out. > I think I already dumped it on the web page a week or so ago... hope this doesn't upset anyone. Maybe we can do an announce, if the changes are interesting enough. Havoc From hp@redhat.com Fri May 4 12:52:19 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 069812E957 for ; Fri, 4 May 2001 12:52:16 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44GsQd27078; Fri, 4 May 2001 12:54:26 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: wm-spec-list@gnome.org Subject: "What's this" From: Havoc Pennington Date: 04 May 2001 12:54:25 -0400 Message-ID: Lines: 11 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Hi, Has anyone implemented or considered implementing the Windows feature where the frame has a ? on it, and you click that to enter "What's this" mode and can then get help on stuff in the window? (Or is it a global mode and you can get help on anything onscreen?) Seems like we could have a simple protocol enabling this. Havoc From tibirna@kde.org Fri May 4 13:12:23 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by mail.gnome.org (Postfix) with ESMTP id C51302DFB4 for ; Fri, 4 May 2001 13:11:29 -0400 (EDT) Received: from there ([64.229.234.15]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> for ; Fri, 4 May 2001 13:11:29 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Cristian Tibirna Organization: KDE To: wm-spec-list@gnome.org Subject: Re: "What's this" Date: Fri, 4 May 2001 13:12:02 -0400 X-Mailer: KMail [version 1.2.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Friday 04 May 2001 12:54, you wrote: > Hi, > > Has anyone implemented or considered implementing the Windows feature > where the frame has a ? on it, and you click that to enter "What's > this" mode and can then get help on stuff in the window? (Or is it a > global mode and you can get help on anything onscreen?) > KDE has it all over the place. You actually get help only for the widgets for which you write "what's this" information explicitely, in KDE. But I believe this could be implemented otherwise in other places. > Seems like we could have a simple protocol enabling this. Hmm? Isn't this in the new NET spec already? -- Cristian Tibirna .. tibirna@sympatico.ca PhD Student .. ctibirna@giref.ulaval.ca .. www.giref.ulaval.ca/~ctibirna KDE contact - Canada .. tibirna@kde.org .. www.kde.org From sopwith@redhat.com Fri May 4 15:14:08 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 73E892C934 for ; Fri, 4 May 2001 15:14:08 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f44JE8S03930 for ; Fri, 4 May 2001 15:14:08 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Fri, 4 May 2001 15:14:07 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Subject: Re: "What's this" In-Reply-To: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Fri, 4 May 2001, Cristian Tibirna wrote: > > Has anyone implemented or considered implementing the Windows feature > > where the frame has a ? on it, and you click that to enter "What's > > this" mode and can then get help on stuff in the window? (Or is it a > > global mode and you can get help on anything onscreen?) > > KDE has it all over the place. You actually get help only for the widgets for > which you write "what's this" information explicitely, in KDE. But I believe > this could be implemented otherwise in other places. > > > Seems like we could have a simple protocol enabling this. > > Hmm? > > Isn't this in the new NET spec already? KDE just uses the Qt hack that does it in one process only. Doing that is easy and irrelevant to this list. A reasonable requirement would be for a "what's this" solution to work inter-application, which would mean coming up with an X protocol to do it. I started looking at this for gnome-libs once - the way I was thinking of doing it was having cursor feedback similar to DnD to point out areas that help can be given for, plus a way to tell the clicked-on area to show its help, once it is clicked. -- Elliot These three lines are for sale at the rate of $50/month. From hp@redhat.com Fri May 4 18:28:30 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 11E322BBE4 for ; Fri, 4 May 2001 18:28:29 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44MTgq03942; Fri, 4 May 2001 18:29:42 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Cristian Tibirna Cc: wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> From: Havoc Pennington Date: 04 May 2001 18:29:42 -0400 In-Reply-To: Cristian Tibirna's message of "Fri, 4 May 2001 13:12:02 -0400" Message-ID: Lines: 13 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Cristian Tibirna writes: > Isn't this in the new NET spec already? > I don't believe so, as Elliot says. I'm thinking of a protocol to do it; either a simple one so you could click ? on a window and get help for stuff inside that window (relatively easy) or a more complex thing so you can get help anywhere on the screen. I'm not sure which one Windows has, actually. Havoc From hp@redhat.com Fri May 4 19:56:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 4110A2BB87 for ; Fri, 4 May 2001 19:56:13 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f44NvbY14667; Fri, 4 May 2001 19:57:37 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Damon McGraw Cc: Cristian Tibirna , wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> <20010504194831.A15323@watchland.org> From: Havoc Pennington Date: 04 May 2001 19:57:37 -0400 In-Reply-To: Damon McGraw's message of "Fri, 4 May 2001 19:48:31 -0400" Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Damon McGraw writes: > > Having it available for the whole screen would be a plus (that way you > could get it for panel applets as well as full apps). But wouldn't it > make more sense if the button (or whatever) to activate it wasn't in a > app? Perhaps somewhere on the panel or something instead? > Seems likely that's not really an issue the protocol would need to address - there would be some way to say "enter whatsthis mode" and the window manager or panel or whatever could provide a button that did that. Havoc From l.lunak@sh.cvut.cz Sat May 5 05:11:16 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from service.sh.cvut.cz (service.sh.cvut.cz [147.32.127.214]) by mail.gnome.org (Postfix) with ESMTP id AABCF2CDA1 for ; Sat, 5 May 2001 05:11:15 -0400 (EDT) Received: from stoupa.sh.cvut.cz (stoupa.sh.cvut.cz [147.32.127.196]) by service.sh.cvut.cz (8.9.3/SH) with ESMTP id LAA15174 for ; Sat, 5 May 2001 11:11:14 +0200 Received: from there (seli@seli.sh.cvut.cz [147.32.122.38]) by stoupa.sh.cvut.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id LAA01583 for ; Sat, 5 May 2001 11:11:14 +0200 Message-Id: <200105050911.LAA01583@stoupa.sh.cvut.cz> Content-Type: text/plain; charset="iso-8859-2" From: Lubos Lunak To: wm-spec-list@gnome.org Subject: Re: "What's this" Date: Sat, 5 May 2001 11:11:12 +0200 X-Mailer: KMail [version 1.2.1] References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Dne so 5. kv=ECten 2001 00:29 jste napsal(a): > Cristian Tibirna writes: > > Isn't this in the new NET spec already? > > I don't believe so, as Elliot says. > > I'm thinking of a protocol to do it; either a simple one so you could > click ? on a window and get help for stuff inside that window > (relatively easy) or a more complex thing so you can get help anywhere > on the screen. I'm not sure which one Windows has, actually. Win2k has 'what's this' only for the active window, the same way it's in= =20 KDE/Qt ( which is IMHO good enough ). > > Havoc > Lubos Lunak -- l.lunak@email.cz ; l.lunak@kde.org http://dforce.sh.cvut.cz/~seli From otaylor@redhat.com Sat May 5 10:30:14 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from fresnel.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 5F7C52E087 for ; Sat, 5 May 2001 10:30:14 -0400 (EDT) Received: by fresnel.labs.redhat.com (Postfix, from userid 2181) id DB90A241C6D; Sat, 5 May 2001 10:30:13 -0400 (EDT) To: wm-spec-list@gnome.org Subject: Re: "What's this" References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> <200105050911.LAA01583@stoupa.sh.cvut.cz> From: Owen Taylor Date: 05 May 2001 10:30:13 -0400 In-Reply-To: Lubos Lunak's message of "Sat, 5 May 2001 11:11:12 +0200" Message-ID: Lines: 47 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Lubos Lunak writes: > Dne so 5. kv=ECten 2001 00:29 jste napsal(a): > > Cristian Tibirna writes: > > > Isn't this in the new NET spec already? > > > > I don't believe so, as Elliot says. > > > > I'm thinking of a protocol to do it; either a simple one so you could > > click ? on a window and get help for stuff inside that window > > (relatively easy) or a more complex thing so you can get help anywhere > > on the screen. I'm not sure which one Windows has, actually. >=20 > Win2k has 'what's this' only for the active window, the same way it's in= =20 > KDE/Qt ( which is IMHO good enough ). Considering that: - "What's this" needs to be activated at least from the window manager title bar. - "What's this" needs to work across embedded subwindows. I don't think you get any essential simplification in implementation from allowing it only in a single window. And I think it's easy to do better than Windows in this respect: - Provide "what's this" globally, and in particular on desktop features such as the taskbar and desktop icons. - Provide feedback during the "what's this operation". (Having to guess what has help, and then restart the operation is the thing I found most annoying trying out this feature in Windows.) (The simplest feedback is simply a yes/no indication as in DND.=20 This is easy to implement and easy to standardize. I suspect it's possible to do better than this, either by providing some visual clue as to what elements have help, or by displaying the help immediately on mouse-over; but I'm not sure that the extra complexity would be worth it.) Regards, Owen From M.Rogers@cs.ucl.ac.uk Sat May 5 11:34:23 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.gnome.org (Postfix) with SMTP id 415192E0AD for ; Sat, 5 May 2001 11:34:23 -0400 (EDT) Received: from moorgate.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 5 May 2001 16:34:19 +0100 To: wm-spec-list@gnome.org Subject: Re: "What's this" In-reply-to: Your message of "04 May 2001 19:57:37 EDT." Date: Sat, 05 May 2001 16:34:18 +0100 Message-ID: <892.989076858@cs.ucl.ac.uk> From: Michael ROGERS Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification >Seems likely that's not really an issue the protocol would need to >address - there would be some way to say "enter whatsthis mode" and >the window manager or panel or whatever could provide a button that >did that. How about this: When the help button is pressed, the help client (could be the WM or a panel applet) grabs the pointer and installs a ? cursor. When the user clicks on an item, the help client sends a client message to the clicked window and releases the pointer. Clients that don't understand the message will ignore it; clients that understand it can display help. This could be a top-level help window, or one of those popup explanations that Windows uses, which don't disappear until you click on something. (Grab the pointer and use redirect override on the tooltip window?) This mechanism could be tied into the existing KDE help system (Qt would detect the client messages and invoke the existing mechanism), so a panel applet or WM could trigger the context-sensitive help attached to KDE widgets. Michael From jg@pa.dec.com Sat May 5 22:05:16 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.gnome.org (Postfix) with ESMTP id 113442CA71 for ; Sat, 5 May 2001 22:05:16 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 44D031C81; Sat, 5 May 2001 21:05:15 -0500 (CDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E7DAFD37; Sat, 5 May 2001 21:05:14 -0500 (CDT) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 897AC42F; Sat, 5 May 2001 22:05:14 -0400 (EDT) Received: from src-mail.pa.dec.com (src-mail.pa.dec.com [16.4.16.35]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 00F6E5EA; Sat, 5 May 2001 22:05:13 -0400 (EDT) Received: by src-mail.pa.dec.com; id TAA09428; Sat, 5 May 2001 19:05:13 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Received: (from pachydrm@localhost) by pachyderm.pa.dec.com (8.11.1/8.11.1) id f4625DU497096; Sat, 5 May 2001 19:05:13 -0700 (PDT) Date: Sat, 5 May 2001 19:05:13 -0700 (PDT) Message-Id: <200105060205.f4625DU497096@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Elliot Lee Cc: wm-spec-list@gnome.org In-Reply-To: Subject: Re: "What's this" Mime-Version: 1.0 Content-Type: text/plain Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification All that is really needed is to decorate the widget windows with the class and instance data from the toolkit, and then one can have an external process do the display. We need that data for things like "Hands off X" to work, and doing it externally means that it can be done to almost any application, independent of the author, in a uniform fashion across toolkits. - Jim > Sender: wm-spec-list-admin@gnome.org > From: Elliot Lee > Date: Fri, 4 May 2001 15:14:07 -0400 (EDT) > To: > Subject: Re: "What's this" > ----- > On Fri, 4 May 2001, Cristian Tibirna wrote: > > > > Has anyone implemented or considered implementing the Windows feature > > > where the frame has a ? on it, and you click that to enter "What's > > > this" mode and can then get help on stuff in the window? (Or is it a > > > global mode and you can get help on anything onscreen?) > > > > KDE has it all over the place. You actually get help only for the widgets > for > > which you write "what's this" information explicitely, in KDE. But I believe > > this could be implemented otherwise in other places. > > > > > Seems like we could have a simple protocol enabling this. > > > > Hmm? > > > > Isn't this in the new NET spec already? > > KDE just uses the Qt hack that does it in one process only. Doing that is > easy and irrelevant to this list. A reasonable requirement would be for a > "what's this" solution to work inter-application, which would mean coming > up with an X protocol to do it. > > I started looking at this for gnome-libs once - the way I was thinking of > doing it was having cursor feedback similar to DnD to point out areas that > help can be given for, plus a way to tell the clicked-on area to show its > help, once it is clicked. > > -- Elliot > These three lines > are for sale > at the rate of $50/month. > > > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com From hp@redhat.com Sun May 6 01:28:10 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 33B1C2CE26 for ; Sun, 6 May 2001 01:28:10 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f465UFd15508; Sun, 6 May 2001 01:30:15 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: jg@pa.dec.com (Jim Gettys) Cc: Elliot Lee , wm-spec-list@gnome.org Subject: Re: "What's this" References: <200105060205.f4625DU497096@pachyderm.pa.dec.com> From: Havoc Pennington Date: 06 May 2001 01:30:15 -0400 In-Reply-To: jg@pa.dec.com's message of "Sat, 5 May 2001 19:05:13 -0700 (PDT)" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification jg@pa.dec.com (Jim Gettys) writes: > All that is really needed is to decorate the widget windows with > the class and instance data from the toolkit, and then one can > have an external process do the display. One problem with that is that we already have a bunch of widgets (or useful-to-communicate-with widget subportions such as sheet cells) that don't have an X window. > We need that data for things like "Hands off X" to work, > and doing it externally means that it can be done to almost any > application, independent of the author, in a uniform fashion > across toolkits. If "Hands off X" is speech recognition stuff, the general GTK plan here (for in-process) is the accessibility API Sun is contributing. Then there is some out-of-process protocol yet to be defined, and a GTK module would be loaded into apps which exported the data obtained from the accessibility API to an alternative/supplemental input/output mechanism living in another process. I think "what's this" is very simple; you just have some way of signaling that you're in "what's this" mode, toolkits highlight widgets with available help; and you send some sort of message to whatever window gets clicked on, and the toolkit pops up the help. App authors just call widget_set_whats_this() and the toolkit magically makes it work. Havoc From olivier.chapuis@free.fr Sun May 6 09:02:42 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by mail.gnome.org (Postfix) with ESMTP id A50FA2BE20 for ; Sun, 6 May 2001 09:02:41 -0400 (EDT) Received: from snoopy.parislyon (paris11-nas2-42-12.dial.proxad.net [212.27.42.12]) by postfix2-1.free.fr (Postfix) with ESMTP id 80AD7C0E9; Sun, 6 May 2001 15:02:39 +0200 (CEST) Received: from snoopy.parislyon (snoopy.parislyon [127.0.0.1]) by snoopy.parislyon (Postfix) with SMTP id B1020242ED; Sun, 6 May 2001 14:54:53 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Olivier Chapuis To: fvwm-announce@fvwm.org, wm-spec-list@gnome.org Subject: fvwm-ewmh-0.1 is released Date: Sun, 6 May 2001 14:54:52 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01050614545200.26369@snoopy.parislyon> Content-Transfer-Encoding: 8bit Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification I am glad to announce the first version of fvwm-ewmh. fvwm-ewmh is constituted by a module, FvwmNetHints, and a patch against the last FVWM beta version (a stable candidate): fvwm-2.3.32. With these FVWM can handle Extended Window Manager Hints from the freedesktop group. This allows, for example, to run FVWM with KDE version 2. This package is alpha, however, it works not so bad on my machine. I announce this release with the hope to get some feedback before releasing version 0.2 which will be released a few days after fvwm-2.4.0 (with no announce to this list). Home Page (Download, Installation, Running, FAQ): http://fvwm-ewmh.sourceforge.net/ Screen Shots: http://fvwm-ewmh.sourceforge.net/screenshots/ Regards, Olivier From Sasha_Vasko@osca.state.mo.us Mon May 7 12:16:56 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 26C0A2DBB2 for ; Mon, 7 May 2001 12:16:56 -0400 (EDT) Subject: Re: "What's this" To: wm-spec-list@gnome.org, Michael ROGERS From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 11:13:56 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 11:14:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > >Seems likely that's not really an issue the protocol would need to > >address - there would be some way to say "enter whatsthis mode" and > >the window manager or panel or whatever could provide a button that > >did that. > > How about this: > > When the help button is pressed, the help client (could be the WM or a > panel applet) grabs the pointer and installs a ? cursor. When the user > clicks on an item, the help client sends a client message to the clicked > window and releases the pointer. Clients that don't understand the > message will ignore it; clients that understand it can display help. Clients should not be bothered with displaying help, unless you want to bloat all of them with basically identical help rendering code. Much cleaner approach would be for single help app. It would query client about context of the mouse click ( basically send it message like: ) on which client should respond with meaningfull text data identifying what help should be displayed - something like . help app then goes and at all known to it locations for this particular information. In case client does not support/respond to thins protocol - then help app simply falls back to using res_name, res_class from client's hints, and goes looking for the man page for this client. X selections would be a good way to implement such a protocol. Compliant clients should acqure ownership of the selection on its top level window something like _NET_HELP. help app then sends them request, passing parameters along in its target property _NET_HELP_REQUEST, created on its own window. And client should respond to it, by placing click context description info into this target property. If client is not an owner of selection _NET_HELP or if it does not respond within reasonable timeout - help app goes on and displays help based on clients Class hints. Something along this lines. > This could be a top-level help window, or one of those popup > explanations that Windows uses, which don't disappear until you click on > something. (Grab the pointer and use redirect override on the tooltip > window?) > > This mechanism could be tied into the existing KDE help system (Qt would > detect the client messages and invoke the existing mechanism), so a > panel applet or WM could trigger the context-sensitive help attached to > KDE widgets. > > Michael > Regards Sasha Vasko From sopwith@redhat.com Mon May 7 12:37:02 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id D79E52CBBE for ; Mon, 7 May 2001 12:37:01 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Gav525322; Mon, 7 May 2001 12:36:57 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 12:36:57 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Jim Gettys Cc: Subject: Re: "What's this" In-Reply-To: <200105060205.f4625DU497096@pachyderm.pa.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Sat, 5 May 2001, Jim Gettys wrote: > All that is really needed is to decorate the widget windows with > the class and instance data from the toolkit, and then one can > have an external process do the display. This is not sufficient to meet the requirements I had in mind. The application whose help is being requested has to be asked to display the help, because it can display it in a manner that best fits the item in question. Also, this approach won't work for widgets without windows... (Not saying that that class/instance info does/doesn't need to be there, of course - if you want it there just file a gtk bug. :-) -- Elliot These three lines are for sale at the rate of $50/month. From sopwith@redhat.com Mon May 7 12:45:02 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 6E5322BAB1 for ; Mon, 7 May 2001 12:45:02 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Giua26941; Mon, 7 May 2001 12:44:56 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 12:44:56 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Cc: , Michael ROGERS Subject: Re: "What's this" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > Clients should not be bothered with displaying help, unless you want to > bloat all of them with basically identical help rendering code. Clients are the only pieces that know how to best display the help. If someone wants to implement the paperclip (whether you like it or not, that case needs to be possible), doing it in the client is the only sane way. If client wishes to use a standardized-help-display-mechanism to show the popup help, then it is entirely possible, but that's a separate problem to be solved - let's not complicate the problem further than it has to be. Right now the only thing to do is find out whether a client has help available for a widget (to provide cursor feedback) and ask the client to provide that help... So, I'm in rough agreement with Havoc on this one, -- Elliot These three lines are for sale at the rate of $50/month. From jg@pa.dec.com Mon May 7 13:20:11 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.gnome.org (Postfix) with ESMTP id 3B3E72BBE0 for ; Mon, 7 May 2001 13:20:11 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 83655CFF; Mon, 7 May 2001 12:20:10 -0500 (CDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4A9A3E18; Mon, 7 May 2001 12:20:10 -0500 (CDT) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id EB7F329B; Mon, 7 May 2001 10:20:09 -0700 (PDT) Received: from src-mail.pa.dec.com (src-mail.pa.dec.com [16.4.16.35]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id DCF0315A; Mon, 7 May 2001 10:20:09 -0700 (PDT) Received: by src-mail.pa.dec.com; id KAA17194; Mon, 7 May 2001 10:20:09 -0700 (PDT) From: jg@pa.dec.com (Jim Gettys) Received: (from pachydrm@localhost) by pachyderm.pa.dec.com (8.11.1/8.11.1) id f47HK97280588; Mon, 7 May 2001 10:20:09 -0700 (PDT) Date: Mon, 7 May 2001 10:20:09 -0700 (PDT) Message-Id: <200105071720.f47HK97280588@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Elliot Lee Cc: Jim Gettys , wm-spec-list@gnome.org In-Reply-To: Subject: Re: "What's this" Mime-Version: 1.0 Content-Type: text/plain Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > From: Elliot Lee > Date: Mon, 7 May 2001 12:36:57 -0400 (EDT) > To: Jim Gettys > Cc: > Subject: Re: "What's this" > ----- > On Sat, 5 May 2001, Jim Gettys wrote: > > > All that is really needed is to decorate the widget windows with > > the class and instance data from the toolkit, and then one can > > have an external process do the display. > > This is not sufficient to meet the requirements I had in mind. The > application whose help is being requested has to be asked to display the > help, because it can display it in a manner that best fits the item in > question. Yes, but it would get 90%, and would allow for help on toolkits that don't do this at all. So how about this scheme, suitably modified to inform clients, so that they can provide help if need be to cover these cases. > > Also, this approach won't work for widgets without windows... > > (Not saying that that class/instance info does/doesn't need to be there, > of course - if you want it there just file a gtk bug. :-) OK, will do :-). Where is the bug reporting system? - Jim -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation jg@pa.dec.com From Sasha_Vasko@osca.state.mo.us Mon May 7 13:27:20 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 70E442BBE0 for ; Mon, 7 May 2001 13:27:20 -0400 (EDT) Subject: Re: "What's this" To: Elliot Lee Cc: From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 12:24:32 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 12:24:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > > > Clients should not be bothered with displaying help, unless you want to > > bloat all of them with basically identical help rendering code. > > Clients are the only pieces that know how to best display the help. If > someone wants to implement the paperclip (whether you like it or not, that > case needs to be possible), doing it in the client is the only sane way. While using proposed selection mechanism, it would be possible for client to respond with some special answer, indicating its desire to "Take over" help displaying. I would estimate, thou, that 95% of Unix/Linux/open source apps will not want to do that. It really is kinda stupid to write a man page, and then code huge piece of code into your application to display basically same information. I understand that this is different for BIG applications like Web Browsers/Word Processors, but we should not be thinking solely about those, and if there is a simple way of implementing generic algorithm, that automagically supports ALL unix applications, without changes required to most of those - we should go with it. Using huge library of man pages is a good thing (TM). > > If client wishes to use a standardized-help-display-mechanism to show the > popup help, then it is entirely possible, but that's a separate problem to > be solved - let's not complicate the problem further than it has to be. > Right now the only thing to do is find out whether a client has help > available for a widget (to provide cursor feedback) and ask the client to > provide that help... Selections mechanism is very simple to implement, and most of those BIG apps that needs it, should already have some selections management code, since things like clipboard are implemented this way. On the other hand standardizing some inferior ad-hoc solution is a nasty, way to go since it will provide a very limited solution (you don't have 2-way communications, so there is no way to find out if app has acknowledged request, and therefore you can't implement any fallback techniques ). And we'll need to live with it till the rest of our lives, and ppl will be pointing fingers, blaming us in very harsh words, and we'll be tearing our hair out, and there will not be a way back, etc. , etc., etc. Sooner or later some 2-way communications will have to be implemented, so why not do it right the first time. It's not like if we don't come up with something today - world collapses. > > So, I'm in rough agreement with Havoc on this one, > -- Elliot Regards Sasha Vasko From sopwith@redhat.com Mon May 7 13:37:20 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 081BF2E1BF for ; Mon, 7 May 2001 13:37:20 -0400 (EDT) Received: from localhost (sopwith@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) with ESMTP id f47Hb9404620; Mon, 7 May 2001 13:37:09 -0400 X-Authentication-Warning: devserv.devel.redhat.com: sopwith owned process doing -bs Date: Mon, 7 May 2001 13:37:09 -0400 (EDT) From: Elliot Lee X-X-Sender: To: Cc: Subject: Re: "What's this" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > I would estimate, thou, that 95% of Unix/Linux/open source apps will > not want to do that. It really is kinda stupid to write a man page Applications are free to share help system solutions, but they need to do it outside of this idea. Given that there are many other ways to use a help system beside "what's this" kind of help, and that the "what's this" help will need to be integrated into the other parts of the help system, it does not make sense to involve the help display part of things in this spec. This idea is not about specifying a common help system for displaying help, only about one particular method of requesting help that needs to be interoperable to benefit the user most. > On the other hand standardizing some inferior ad-hoc solution is a > nasty, way to go since it will provide a very limited solution (you > don't have 2-way communications, so there is no way to find out if app > has acknowledged request, and therefore you can't implement any > fallback techniques ). Cursor feedback was part of the requirements I gave. If an app doesn't participate in that, then you can do your fallback stuff. -- Elliot These three lines are for sale at the rate of $50/month. From hp@redhat.com Mon May 7 14:17:59 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 72FA92E249 for ; Mon, 7 May 2001 14:12:14 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f47IEAD22635; Mon, 7 May 2001 14:14:10 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org, Michael ROGERS Subject: Re: "What's this" References: From: Havoc Pennington Date: 07 May 2001 14:14:10 -0400 In-Reply-To: Sasha_Vasko@osca.state.mo.us's message of "Mon, 7 May 2001 11:13:56 -0500" Message-ID: Lines: 24 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Sasha_Vasko@osca.state.mo.us writes: > Clients should not be bothered with displaying help, unless you want to > bloat all of them with basically identical help rendering code. The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. There are two problems with the approach you mention: - people want something higher-level than text in the help, e.g. a simple HTML-like subset with links, etc. - help needs to work within a client even if no "help manager" app is running; i.e. the client needs a fallback implementation in any case, it can't rely on a desktop runtime environment being active. So you can't eliminate the toolkit code in any case. (And Qt already has this code, anyhow.) man pages certainly aren't the kind of help we're discussing here; what's this help is just a paragraph on the specific widget that's been clicked. Sort of longer tooltips, maybe with embedded links to the full documentation for the app. Havoc From Sasha_Vasko@osca.state.mo.us Mon May 7 15:26:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 7E7E72DB6D for ; Mon, 7 May 2001 15:26:13 -0400 (EDT) Subject: Re: "What's this" To: Havoc Pennington Cc: wm-spec-list@gnome.org, Michael ROGERS From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 14:23:25 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:23:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > Sasha_Vasko@osca.state.mo.us writes: > > Clients should not be bothered with displaying help, unless you want to > > bloat all of them with basically identical help rendering code. > > The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. > wait a sec. Are we disscussing "what's this" feature applicable only to toolkits ? If so then I retract all my proposals. I thought that you wanted to be able to get help not only on toolkit windows but universally on any object on the desktop. I don't think that any sane window manager is going to implement its own hyperlinked help browser - the best you can count on is popping up mozilla or term with man page/faqs displayed in it. What that brings you to is that user may get all kinds of help systems from different desktop objects - from GTK apps - one, from QT apps - another and completely different from something else, and nothing at all from most other things. All of those things will have different look and feel, which is not nice. If you really want to implement global help system, you have to think about signle app, that can display help for both GTK/Qt as well as the rest of the world. If all you need is internal toolkit help browser - then why bother with standard? I don't think it will make any sense at all for window manager to implement "What's it" button which will work only in GTK/QT, and will not work correctly even on its own interface elements. Besides do you actually see all the apps linked as dynamically only from now onwards? Cos if you link it statically - you do get bloat issue. > There are two problems with the approach you mention: > > - people want something higher-level than text in the help, > e.g. a simple HTML-like subset with links, etc. It's not difficult to implement help browser that would intelligently distinguish between help available in HTML, XML, man pages or any other format. And in fact man pages could be displayed as a hyperlinked text, and are very nice in that way. > > - help needs to work within a client even if no "help manager" app is > running; i.e. the client needs a fallback implementation in any > case, it can't rely on a desktop runtime environment being active. > So you can't eliminate the toolkit code in any case. (And Qt > already has this code, anyhow.) Well, if globally active help system is not running - then this entire disscussion is not applicable anyways - each client will have to rely upon itself entirely. The interesting implication is that you do not really need window manager involvement at all - you click on desktop icon/menu item-> that will launch help app -> help app grabs pointer and waits for a click -> then it traverses window tree in order to find out any parent window with wm hints set. etc. etc. etc. > man pages certainly aren't the kind of help we're discussing here; > what's this help is just a paragraph on the specific widget that's > been clicked. Sort of longer tooltips, maybe with embedded links to > the full documentation for the app. It still has to be a paragraph out of complete set of docs - and as such I do not see much difficulty in displaying particular topic out of HTML file, or even a man page for that matter. Anyways I just proposed the way it could be implemented using standard X approach. I don't seem to see any other alternative proposals, except for Michael Roger's one , which is basically the same as what I proposed, only with messages instead of selection( which is not good for 2-way communications). So what is this exactly we are arguing about ? What is your alternative? > > Havoc From Sasha_Vasko@osca.state.mo.us Mon May 7 15:33:11 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id D866D2CE3D for ; Mon, 7 May 2001 15:33:08 -0400 (EDT) Subject: Re: "What's this" To: , Elliot Lee Cc: From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 14:30:19 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:30:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, 7 May 2001 Sasha_Vasko@osca.state.mo.us wrote: > > > I would estimate, thou, that 95% of Unix/Linux/open source apps will > > not want to do that. It really is kinda stupid to write a man page > > Applications are free to share help system solutions, but they need to do > it outside of this idea. Given that there are many other ways to use a > help system beside "what's this" kind of help, and that the "what's this" > help will need to be integrated into the other parts of the help system, > it does not make sense to involve the help display part of things in this > spec. This idea is not about specifying a common help system for > displaying help, only about one particular method of requesting help that > needs to be interoperable to benefit the user most. X Selections is the most standrad and interoperable way to implement such things. It has been specifically designed for this purpose. > > On the other hand standardizing some inferior ad-hoc solution is a > > nasty, way to go since it will provide a very limited solution (you > > don't have 2-way communications, so there is no way to find out if app > > has acknowledged request, and therefore you can't implement any > > fallback techniques ). > > Cursor feedback was part of the requirements I gave. If an app doesn't > participate in that, then you can do your fallback stuff. What cursor feedback exactly are you talking about. Care to provide some definition ? Or did I miss something ? Besides any cursor manipulations by client apps are highly discouraged in X. > -- Elliot From hp@redhat.com Mon May 7 15:50:46 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from icon.labs.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200]) by mail.gnome.org (Postfix) with ESMTP id 5EE832CB80 for ; Mon, 7 May 2001 15:50:46 -0400 (EDT) Received: (from hp@localhost) by icon.labs.redhat.com (8.11.2/8.11.2) id f47Jqf908069; Mon, 7 May 2001 15:52:41 -0400 X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com using -f To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org, Michael ROGERS Subject: Re: "What's this" References: From: Havoc Pennington Date: 07 May 2001 15:52:41 -0400 In-Reply-To: Sasha_Vasko@osca.state.mo.us's message of "Mon, 7 May 2001 14:23:25 -0500" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification Sasha_Vasko@osca.state.mo.us writes: > > So what is this exactly we are arguing about ? What is your alternative? > My original thought on this was just a spec for putting the ? button in the WM decoration. That is, the client would set a hint "I support what's this" and the WM would send a message if the user clicked the what's this button. But the actual help is just within the app. The more ambitious idea is that clicking what's this works for the entire desktop. This would require a protocol similar to drag-and-drop, which would normally be implemented in toolkits (since the only people who no longer use toolkits are people writing window managers, pretty much, and even the newer WMs use a toolkit whenever they want to display dialogs and such). This would work similar to drag-and-drop; a client would enter what's this mode (grab pointer, change cursor); somehow notify other clients that the mode was entered so they could highlight targets; as you moved the pointer around, it would change to indicate whether you were on a target; when you then clicked on a target, the target would receive some sort of message and reply back to the whatsthis-mode owner app that it should release the grab and leave the mode. There is a problem with inconsistency between toolkits, but this same problem exists for all aspects of toolkit look-and-feel, and it can be solved via theme coordination in the same way we'll solve e.g. button appearance. Havoc From raster@asterman.com Mon May 7 15:54:37 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from asterman.com (nat-hdqt.valinux.com [198.186.202.17]) by mail.gnome.org (Postfix) with ESMTP id 86D802CB80 for ; Mon, 7 May 2001 15:54:36 -0400 (EDT) Received: (from raster@localhost) by asterman.com (8.11.0/8.11.0) id f47Iuw925915; Mon, 7 May 2001 11:56:58 -0700 Message-Id: <200105071856.f47Iuw925915@asterman.com> Date: Mon, 7 May 2001 11:56:58 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: "What's this" To: Sasha_Vasko@osca.state.mo.us Cc: hp@redhat.com, wm-spec-list@gnome.org, M.Rogers@cs.ucl.ac.uk In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On 7 May, Sasha_Vasko@osca.state.mo.us scribbled: > > > Sasha_Vasko@osca.state.mo.us writes: > > > Clients should not be bothered with displaying help, unless you want to > > > bloat all of them with basically identical help rendering code. > > > > The code will be in toolkits, e.g. GTK, Qt. So there's no bloat issue. > > > > wait a sec. Are we disscussing "what's this" feature applicable only to > toolkits ? If so then I retract all my proposals. > > I thought that you wanted to be able to get help not only on toolkit > windows > but universally on any object on the desktop. I don't think that any > sane window manager is going to implement its own hyperlinked help I'm not averse to doing it... :) it's kinda fun.. alreayd implimented one for E16 (dox) because i just wanst willing to wait 10 secons for netscape to pop up with help info in it for some simple help docs with inline diagrams and links within the doc... :) the wm doesnt have to actually impliment the cod if you dont want to.. it coudl pass it off to a helper app installed and exec it passing the info along... > browser - the best you can count on is popping up mozilla or term with > man page/faqs displayed in it. What that brings you to is that user may get > all kinds of help systems from different desktop objects - from GTK apps - > one, > from QT apps - another and completely different from something else, > and nothing at all from most other things. All of those things will > have different look and feel, which is not nice. If you really want to > implement global help system, you have to think about signle app, that can > display help for both GTK/Qt as well as the rest of the world. unless you write it - it will never happen. both camps will do (and alreayd have done) their own. you can do one - but neither side will use it. welcome to the world fo warring desktops. we can standardize but each mob have their own implimentation of those standards - and you either pick one side or the other or you get a mish-mash of them. you're call as a user. personally i'm happy to just impliment my own stuff for myself and be done with it :) saves me having to choose choose a job .. choose a family.. choose a fucking big television.. choose life. :) > If all you need is internal toolkit help browser - then why bother with > standard? I don't think it will make any sense at all for window manager > to implement "What's it" button which will work only in GTK/QT, and > will not work correctly even on its own interface elements. > > Besides do you actually see all the apps linked as dynamically only > from now onwards? Cos if you link it statically - you do get bloat issue. -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com VA Linux Systems raster@deephackmode.org Mobile Phone: +1 408 887 3163 Work Phone: +1 510 687 7069 From Sasha_Vasko@osca.state.mo.us Mon May 7 17:18:17 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id A78A32E318 for ; Mon, 7 May 2001 17:18:17 -0400 (EDT) Subject: Re: "What's this" To: wm-spec-list@gnome.org From: Sasha_Vasko@osca.state.mo.us Date: Mon, 7 May 2001 16:15:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/07/2001 04:15:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > Sasha_Vasko@osca.state.mo.us writes: > > > > So what is this exactly we are arguing about ? What is your alternative? > > > > My original thought on this was just a spec for putting the ? button > in the WM decoration. That is, the client would set a hint "I support > what's this" and the WM would send a message if the user clicked the > what's this button. But the actual help is just within the app. Hmm, is thtat really all that simple? I mean upon receiving such a message app would have to grab pointer. But pointer may still be on titlebar - which is window Managers area of resposibility. Just as well user mayhave gone and quickly clicked somewhere else, while "What's this" message was traveling from window manager to client app. > The more ambitious idea is that clicking what's this works for the > entire desktop. This would require a protocol similar to > drag-and-drop, which would normally be implemented in toolkits (since > the only people who no longer use toolkits are people writing window > managers, pretty much, and even the newer WMs use a toolkit whenever > they want to display dialogs and such). > > This would work similar to drag-and-drop; a client would enter what's > this mode (grab pointer, change cursor); somehow notify other clients > that the mode was entered so they could highlight targets; as you > moved the pointer around, it would change to indicate whether you were > on a target; when you then clicked on a target, the target would > receive some sort of message and reply back to the whatsthis-mode > owner app that it should release the grab and leave the mode. well, that could be achieved by using same XDND with some custom Action type (AFAIK). BTW XDND does uses selection :) > There is a problem with inconsistency between toolkits, but this same > problem exists for all aspects of toolkit look-and-feel, and it can be > solved via theme coordination in the same way we'll solve e.g. button > appearance. Heh, still idea of linking whole HTML widget into tiny clock app for the sole purpose of being able to display some short info strikes me as monstrous. > > Havoc > Sasha Vasko From damon@watchland.org Fri May 4 19:33:13 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from over.watchland.org (WATCHLAND.ORG [208.138.115.93]) by mail.gnome.org (Postfix) with ESMTP id 6B8112BB87 for ; Fri, 4 May 2001 19:33:13 -0400 (EDT) Received: from debian ([192.168.1.2] ident=mail) by over.watchland.org with esmtp (Exim 3.12 #1 (Debian)) id 14vpAE-0004ey-00; Fri, 04 May 2001 19:39:10 -0400 Received: from damon by debian with local (Exim 3.12 #1 (Debian)) id 14vpJH-00040c-00; Fri, 04 May 2001 19:48:31 -0400 Date: Fri, 4 May 2001 19:48:31 -0400 From: Damon McGraw To: Havoc Pennington Cc: Cristian Tibirna , wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010504194831.A15323@watchland.org> References: <20010504171129.MFKJ16174.tomts7-srv.bellnexxia.net@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hp@redhat.com on Fri, May 04, 2001 at 06:29:42PM -0400 Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification IIRC Windows provides only the "what's this" for the current application and then only if context help is available for the widget that you click on. This help is also available (in most apps) by pressing F1 when the widget has focus. Having it available for the whole screen would be a plus (that way you could get it for panel applets as well as full apps). But wouldn't it make more sense if the button (or whatever) to activate it wasn't in a app? Perhaps somewhere on the panel or something instead? Damon ++ 04/05/01 18:29 -0400 - Havoc Pennington: > > Cristian Tibirna writes: > > Isn't this in the new NET spec already? > > > > I don't believe so, as Elliot says. > > I'm thinking of a protocol to do it; either a simple one so you could > click ? on a window and get help for stuff inside that window > (relatively easy) or a more complex thing so you can get help anywhere > on the screen. I'm not sure which one Windows has, actually. > > Havoc > > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list From mrogers@cs.ucl.ac.uk Mon May 7 16:31:51 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from clustermail.minx.net.uk (node-1.minx.net.uk [212.85.249.131]) by mail.gnome.org (Postfix) with ESMTP id 61DDD2C865 for ; Mon, 7 May 2001 16:31:51 -0400 (EDT) Received: from [212.1.154.68] (helo=dexter) by clustermail.minx.net.uk with esmtp (Exim 3.22 #2) id 14wri8-0005JB-00; Mon, 07 May 2001 21:34:35 +0100 Received: from michael by dexter with local (Exim 3.12 #1 (Debian)) id 14wrQv-00005C-00; Mon, 07 May 2001 21:16:41 +0100 Date: Mon, 7 May 2001 21:16:41 +0100 To: Sasha_Vasko@osca.state.mo.us Cc: wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010507211641.B253@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sasha_Vasko@osca.state.mo.us on Mon, May 07, 2001 at 02:30:19PM -0500 From: Michael Rogers Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Mon, May 07, 2001 at 02:30:19PM -0500, Sasha_Vasko@osca.state.mo.us wrote: > What cursor feedback exactly are you talking about. Care to provide some > definition ? Or did I miss something ? Besides any cursor manipulations > by client apps are highly discouraged in X. I think the idea is this: When the user clicks on the "What's this?" button, the owner of the button (let's call it the help client) grabs the pointer. Whenever the pointer enters a new window, the help client sends a message to that window. The owner of the window can install a new cursor to indicate that help is available for that widget (similar to the way DnD targets can identify themselves). Old toolkits will not understand the message, so the cursor will not change, so the user will know that no help is available. When the pointer leaves the window, the help client sends another message so the old cursor can be reinstalled. (The client should reinstall the old cursor after a few seconds if no messages are received from the help client, in case the help client has crashed.) When the user clicks on a widget, the help client sends a message to the clicked window and releases the pointer. The clicked widget can show simple tooltip-style help, or launch a standalone help browser if necessary. Neither method involves much bloat. The client doesn't need its own help browser. It could check the value of some environment variable / X resource / GConf resource to find out which app to launch, but that's really outside the scope of the WM spec (although it should probably be standardised in another freedesktop document). Michael From julian.adams@gmx.net Wed May 9 04:17:47 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from cmailg7.svr.pol.co.uk (cmailg7.svr.pol.co.uk [195.92.195.177]) by mail.gnome.org (Postfix) with ESMTP id D43272BB23 for ; Wed, 9 May 2001 04:17:46 -0400 (EDT) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14xPAF-0008AM-00; Wed, 09 May 2001 09:17:43 +0100 Received: from modem-33.leopard-shark.dialup.pol.co.uk ([62.137.37.161] helo=babybel.at_home) by mail18.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14xPAD-0003pp-00; Wed, 09 May 2001 09:17:42 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Julian Adams Reply-To: julian.adams@gmx.net To: Havoc Pennington Subject: Re: Publish revised spec ? Date: Wed, 9 May 2001 09:17:25 +0100 X-Mailer: KMail [version 1.2] Cc: Owen Taylor , wm-spec-list@gnome.org References: <5.0.2.1.0.20010504104523.00b1d4a0@pop.freeserve.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <01050909172500.07084@babybel.at_home> Content-Transfer-Encoding: 8bit Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Friday 04 May 2001 14:29, Havoc Pennington wrote: > I think I already dumped it on the web page a week or so ago... hope > this doesn't upset anyone. Maybe we can do an announce, if the changes > are interesting enough. > > Havoc Added a change history for 1.1. The changes are very dull, but I did it for completeness (and so you can just scan the change history). Let's get this up on the web as 1.1. Diff below: cvs -z3 diff -u wm-spec.sgml Index: wm-spec.sgml =================================================================== RCS file: /home/freedesktop/wm-spec/wm-spec.sgml,v retrieving revision 1.11 diff -u -r1.11 wm-spec.sgml --- wm-spec.sgml 2001/04/22 10:14:49 1.11 +++ wm-spec.sgml 2001/05/09 02:51:04 @@ -1167,6 +1167,32 @@ Change history + Changes since 1.0 + + +Fix doctype, add author info, update data. + + +Change specification description wording to be more inclusive, and to reflect the joint nature of the specification. + + +Fix miscellaneous typographical, grammar and spelling errors. + + +Clarified _NET_SUPPORTED to include ALL atoms, not just the property names. + + +Various corrections to use of MUST and SHOULD. + + +Fix problem in _NET_WM_ICON where 'bytes' should have been 'cardinals' + + +Replaced ISO-8559-1 characters with entities. + + + + Changes since 1.0pre5 From Sasha_Vasko@osca.state.mo.us Wed May 9 09:59:39 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from oscln0005.osca.state.mo.us (mail.osca.state.mo.us [168.166.59.193]) by mail.gnome.org (Postfix) with ESMTP id 2A4A82BF61 for ; Wed, 9 May 2001 09:59:39 -0400 (EDT) Subject: Re: "What's this" To: Sasha_Vasko@osca.state.mo.us, Michael Rogers Cc: wm-spec-list@gnome.org From: Sasha_Vasko@osca.state.mo.us Date: Wed, 9 May 2001 08:56:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on OSCLN0005/OSCA/Courts/Judicial(Release 5.0.6a |January 17, 2001) at 05/09/2001 08:56:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification > On Mon, May 07, 2001 at 02:30:19PM -0500, Sasha_Vasko@osca.state.mo.us wrote: > > What cursor feedback exactly are you talking about. Care to provide some > > definition ? Or did I miss something ? Besides any cursor manipulations > > by client apps are highly discouraged in X. > > I think the idea is this: > > When the user clicks on the "What's this?" button, the owner of the button > (let's call it the help client) grabs the pointer. Whenever the pointer > enters a new window, the help client sends a message to that window. The > owner of the window can install a new cursor to indicate that help is You cannot install new cursor since help client has an active grab on the pointer at the moment > available for that widget (similar to the way DnD targets can identify > themselves). Old toolkits will not understand the message, so the cursor > will not change, so the user will know that no help is available. When > the pointer leaves the window, the help client sends another message so > the old cursor can be reinstalled. (The client should reinstall the old > cursor after a few seconds if no messages are received from the help > client, in case the help client has crashed.) You cannot query what was the old cursor > When the user clicks on a widget, the help client sends a message to the > clicked window and releases the pointer. Actuall protocol used by XDND is much more complicated and includes complicated 2-way message exchange, and it does takes ownership of selection, but mostly for the purpose of avoiding possible situation where 2 DND operations will be attempted at the same time. Like I said before - "what's this" stuff could be done by simply utilizing XDND protocol with custom action, like _NET_XdndActionWhatsThis for example. > The clicked widget can show simple tooltip-style help, or launch a > standalone help browser if necessary. Neither method involves much > bloat. The client doesn't need its own help browser. It could check the > value of some environment variable / X resource / GConf resource to find > out which app to launch, but that's really outside the scope of the WM > spec (although it should probably be standardised in another freedesktop > document). yes it is outside of the scope of this specs. Still, just as a general idea, think about it: wouldnot that be nice if there was a single app that could have given you a help on each and every client/widget on the desktop in some standard view, no matter if the widget is from GTK or from KDE or other place ? Maybe not exactly a "Whats this" feature - sort of like man page browser only smart enough to query what text should be displayed from the client window by itself - with no user typing in a name to look up. > Michael Cheers Sasha Vasko From mrogers@cs.ucl.ac.uk Wed May 9 15:13:21 2001 Return-Path: Delivered-To: wm-spec-list@gnome.org Received: from clustermail.minx.net.uk (node-3.minx.net.uk [212.85.249.133]) by mail.gnome.org (Postfix) with ESMTP id EA82C2DE3B for ; Wed, 9 May 2001 15:13:20 -0400 (EDT) Received: from [212.1.141.153] (helo=dexter) by clustermail.minx.net.uk with esmtp (Exim 3.22 #4) id 14xZRo-00038f-00 for wm-spec-list@gnome.org; Wed, 09 May 2001 20:16:34 +0100 Received: from michael by dexter with local (Exim 3.12 #1 (Debian)) id 14xZM7-00007O-00 for ; Wed, 09 May 2001 20:10:39 +0100 Date: Wed, 9 May 2001 20:10:39 +0100 To: wm-spec-list@gnome.org Subject: Re: "What's this" Message-ID: <20010509201039.D252@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sasha_Vasko@osca.state.mo.us on Wed, May 09, 2001 at 08:56:29AM -0500 From: Michael Rogers Sender: wm-spec-list-admin@gnome.org Errors-To: wm-spec-list-admin@gnome.org X-BeenThere: wm-spec-list@gnome.org X-Loop: wm-spec-list@gnome.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: Window manager specification On Wed, May 09, 2001 at 08:56:29AM -0500, Sasha_Vasko@osca.state.mo.us wrote: > You cannot install new cursor since help client has an active grab on the > pointer at the moment Sorry, I didn't realise (although that makes sense now I think about it!). Maybe XDnD is the best way to do it then. > Still, just as a general idea, think about it: wouldnot that be nice if > there was a single app that could have given you a help on each and > every client/widget on the desktop in some standard view, no matter if > the widget is from GTK or from KDE or other place ? Maybe not exactly > a "Whats this" feature - sort of like man page browser only smart > enough to query what text should be displayed from the client window by > itself - with no user typing in a name to look up. But Gnome and KDE would create their own implementations so you would still have the problem of choosing which one to launch! :) We should provide a way for the user to choose which app will be used to display help, in a way that any desktop environment or WM can understand. The user gets the "standard view", and the DEs get to bitch about who provides the best help browser. :) One possibility is to use ~/.mime.types - the user can choose which app should handle the content type x-documentation/man, for example, and when an app wants to display a man page it can launch the program that's registered to handle that MIME type. You would have different MIME types for different types of documentation (x-documentation/info, x-documentation/html, x-documentation/plain), which might point to the same versatile help browser or to standalone viewers. Michael