Re: Access to desktop information - updated patch
Yes and no. Access to information, yes, but also the internal
interface should be window-system-independent until it dispatches at
the lowest level. I don't much like exposing these x-do-window-op,
ms-do-window-op, ... functions (cf my opinion on `turn-on-foo-mode',
`turn-off-foo-mode'); I would prefer a single do-window-op function
that dispatches to the underlying code. Thus "console methods".
It also avoids doing lisp magic and risking bugs :D
> current-desktop is really a property of a console or device
(not a
> frame), but there is no analogous access to "console properties".
I'm not sure it's worth implementing console properties in general,
but it's certainly possible to add a current_desktop method to struct
console_methods. This would then be automagically dispatched to by
(current-desktop console).
I just checked, the beos code seems to map the BScreen object in device
code, as it uses it to return DM_size_workspace.
It currently only uses the default screen without enumerating, which
might break later when we implement multiple screens in Haiku, but it's
not really top on the list anyway.
cf.
http://www.haiku-os.org/legacy-docs/bebook/BScreen.html
OTH, the screen size is supposed to change depending which workspace is
shown.
Though we don't use this feature much anymore with LCD panels.
As for current_desktop, as I said we currently handle "workspaces" as a
bitmask for windows, but it's easy to return the current one's ID, and
check if the bit is set on a window (frame).
Similarly, I think on-desktop could (and probably should) be
implemented as a frame or console method. The advantage of
implementing as a console method is that you could pass a generic
window ID in console-dependent fashion, such as UINT_32_BIT (IIRC)
for
X11.
That'd be a pointer for BeOS, but it's doable as well.
François.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta