Perhaps a good thing to do at this point as well would be to create
a running X11 application down in the Dock like other normal OS X
apps just to be able to quickly see and terminate (or perhaps "Keep
In Dock") rapidly.
This is very simple to do, here's how: (I'm going to assume that some
of the people reading are not super-X-savvy)
Background:
One of the fundamental design decisions of X is policy-neutrality: if
X can get away with *not* doing/managing it, then don't do/manage it.
This includes controlling window positioning, size, borders,
resizing, and title-bars. Also, launching apps, drawing of any kind
besides bitmaps (until recent extensions, which allow for bitmaps-
with-alpha), and almost anything you would associate with a GUI. What
X provides is really quite small. Basically, bitmap drawing regions
that are clipped so as to appear to be layered. Until recent
extensions, the clipped parts were discarded, unless requested (still
not required) to be preserved.
Much of what you think of as the GUI is handled by what's called a
window manager. Apple's X11 comes with one called "quartz-wm", which
provides the appearance of Aqua title-bars on your X apps.
Solution:
It would be exceedingly simple for someone who can write a window
manager, to write one (or adapt quartz-wm if said person works at
Apple) that creates a Dock icon for each separate application.
Problems with this stem from the difficulty in determining what is
one application, and what is a whole slew of unrelated windows. A
side-effect of the X model is that menus are *separate windows*,
meaning that a Dock icon for each window would get really stupid
really fast. Solution: All windows originating from the same
executable process have their own Dock icon. The windowing hints
provided by most toolkits to the window manager can also be used to
either hide some processes from appearing in the Dock, but still
displaying windows, or allowing one process to appear as several in
the Dock.
Also, because each X window (bitmap) is hierarchically attached to a
parent (up to the "root" window), these heirarchies can be used to
determine which windows should/should-not appear in the dock. For
example, a process may display a window as a child of another
process's window (to provide a consistent GUI provided by multiple
processes), and as such should not be in the Dock even though it is a
separate process creating windows.
1st) get X11 set up to operate like a service and simply list
running X11 apps under a hierarchy tree or a flat menu in the
dropdown.
Excellent Idea. I have long wanted to remove X11.app from app status,
but making a Menu Extra to cover the few remaining controls is
something that had not occurred to me. I think the preferences should
be placed inside System Preferences, including managing the
"Applications" menu currently in X11.app (or maybe do-away with that?)
Trying to keep it as simple as possible for the developers who
would need to make changes.
2nd) Push all X11 App icons into the Dock and integrate the
pasteboard/x11 copy/paste/kill, etc.
This is easily achievable via a simple window-manager, see above.
buffers more thoroughly. So, for example, a ctrl-k will place the
contents into the yank buffer that exists in OS X pasteboard or
whatever is used to store that as well. Basically creating a
uniform feel/user interface between the window servers.
This already exists to a limited degree. Currently, quartz-wm
monitors the X "CLIPBOARD SELECTION" (not PRIMARY or SECONDARY), and
syncs it with Aqua's pasteboard. I think that this should be moved
into the X11.app-replacement so that the updates are immediate. This
of course will only work for apps that use the X CLIPBOARD, which
mose toolkit apps do (iThink).
3rd) Eventually extract the X11 applications' menus information and
place them into the Menubar so that they truly start to have the OS
X control/feel.
This is entirely up to the toolkits, and so will likely never happen.
KDE provides functionality to do its own top-of-the-screen menubar,
and depending on the window-manager hints it provides, the X11.app-
replacement may be able to guess at this and hide the Aqua menubar to
allow this Mac-like-KDE-menubar to take its place while that app is
in the foreground. This would be doable from the window manager, as
Aqua already provides API for hiding the menu-bar (in games, for
instance), though error-prone, and would be messy with the Apple-menu
and the right-hand-side Menu Extras. I think that this would be
doable, though it would require a significant bit of code relating to
the toolkits.
4th) skin the interfaces appropriately. Create an OS X skin for
gtk, kde, etc. interfaces and apply this appropriately to their
applications. Also remove (not sure how this would be done, but it
seems that there would be a way) the built-in menubars for
applications and just use the standard OS X Menubar...
Aqua skins exist for KDE-/gtk-based apps, and some are quite good.
They may (or may not) be difficult to find because Apple Legal
reserves the word Aqua. Removing the per-window-menubar again has to
do with the toolkit and so would be almost impossible to do without
modifying the toolkits, though when using KDE's top-of-screen-
menubar, the ones inside the window disappear.
Any thoughts, additions, ideas, corrections, improvements, critique
as to why things won't work? I really think that a direction such
as this would help X11 and some bases of users quite a bit to
really enjoy Mac OS X more while using certain applications. This
would also help to alleviate issues such as OpenOffice not
integrating well; why integrate it and rewrite it if there is no
need and the feel of OS X is maintained and the performance is the
same? It's all about keeping uniformity and simplicity for the user.
I agree completely. I think that the (relatively) minor amount of
work that Apple would need to put in to do this would be well-worth
it, although most of their customers who need this functionality are
likely willing to put up with a very-not-mac-like-interface.
Thanks for the inquiry for thinking that this is interesting!
-George
Thanks for your ideas, lets hope that somebody at apple is listening,
and cares!
JP
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden
