Re: Context help: what's this?



On  1 Dec, Owen Taylor scribbled:
->  
->  [ Going off a bit on a tangent on the subject of what-is-this help -
->    Xdnd people CC'd ]
->  
->  Matthias Ettrich <ettrich@troll.no> writes:
->  
->  > Yet another suggestion for the specs:
->  > 
->  >          NET_WM_CONTEXT_HELP
->  > 
->  > A simple, standard-compliant wm protocol similar to WM_TAKE_FOCUS
->  > (Those who don't know these, please see XSetWMProtocols, XGetWMProtocols for
->  > details).
->  > 
->  > If a window propagates that it speaks this protocol, the WM may offer a way to
->  > invoke context help on the window. This can be done with a '?'-button, a menu
->  > item or whatever. When the user selects or invokes context help, the WM sends 
->  > a client message to the window. Format is the same as with the other wm
->  > protocols:
->  > 
->  >   ev.xclient.type = ClientMessage;
->  >   ev.xclient.window = wm_protocols;
->  >   ev.xclient.message_type = net_wm_context_help;
->  >   ev.xclient.format = 32;
->  >   ev.xclient.data.l[0] = net_wm_context_help;
->  >   ev.xclient.data.l[1] = <the wm's current time>;
->  > 
->  > 
->  > Some background information: the '?' button on dialogs is standard on
->  > MS-Windows. It is a nifty possibility to provide useful and fast help without
->  > cluttering the dialog windows with yet another pushbutton. The '?' invokes
->  > so-called "What's This?" help, that lies somewhere between tool-tips and a
->  > full-blown help system. Dialogs also often have a "help" button, but this is
->  > supposed to fire up the real help system.
->  
->  Matthias's suggestion covers the WM-spec issues of decoration
->  and informing the window to start the operation. It is perfectly
->  sufficient to implement what Microsoft has. However, IMO, the
->  Windows implementation is lacking in a couple of ways:
->  
->   - Context sensitive help is confined to a single window for a single
->     operation.
->   - Context sensitive help doesn't give any feedback during the operation
->  
->  The lack of feedback especially is somewhat annoying in Windows
->  annoying since if you click on somewhere which doesn't have help, you
->  need to go back to the titlebar to start over again.
->  
->  To provide these, you'd need to send messages to the underlying window,
->  and get status messages back - this is pretty much identical to a
->  drag-and-drop protocol.
->  
->  So, it is, in many ways sensible to reuse the Xdnd protocol for this,
->  and simple make what-is-this help a drop of the special type
->  'application/x-what-is-this'.
->  
->  You wouldn't necessarily get 100% code reuse with drag-and-drop code
->  on the source or target side, but there is quite a bit that would be
->  reusable, and the protocol is completely reusable.
->  
->  Note that this gives you the ability to do what-is-this operations
->  on UI portions that don't have obvious titlebars 
->  
->   - panels and docks
->   - the desktop
->  
->  Etc.
->  
->  There are a few downsides / concerns to doing this globally instead of
->  window-by-window:
->  
->   * Who handles the 'source' side? 
->  
->     - The application window where '?' is clicked? 
->       For different windows, you might get different cursors, and subtly
->       different behaviors.
->  
->     - The window manager? Then you need to implement a subset of the
->       source side of the Xdnd protocol in the WM. (This is probably
->       ~100-200 lines of code.)
->  
->     - Some external app. That is, you send a a message to the root window,
->       instead of the client window, and let it be picked up from there.
->  
->     Of these, the first two are probably the better choices.
->  
->   * The user has somewhat less direction as to when a 'what-is-this'
->     operation is going to be useful. In Windows, the '?' icon only
->     appears in dialogs that are presumbed to be 100% help-enabled.
->  
->     For this reason, you probably want to still reserve the '?' icon
->     for title bars of windows that explicitely request the help
->     icon. But there might be other ways to start the context-sensitive
->     help operation, such as a window-manager or system-menu option.
->  
->  Thoughts? I suspect we'll do this internally for the GNOME implemenation,
->  even if it isn't a standard. But if people think the ability
->  to make the operation global is useful, it would be good for it
->  to be a standard thing.

infact i just had a brain fart.. why woudl we confin this JUST to
context sensitive help? why nto allow applicatiosns to request buttons
in the border that can be anythign they like?

basiucally allow them to set:
_NET_BORDER_BUTTONS[StringList]

each member of the scrtip list is a normal ascii name for a button - we
can have serevral by default:
Help
Close
Iconfiy

etc.
the WM can determine if these buttons are alreayd provided by the
border, or if it should/can add them, and similarly the WM can reply
with clientmessages as to which button was activated (or menu element)
the strigns also translate to menu entries too :)

just an idea..



-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com     raster@valinux.com
                                    raster@enlightenment.org raster@linux.com
				    raster@zip.com.au



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]