X Resource Monitoring
Just for
Jeff, improved blame assignment for memory hogging.
(This post was originally found at http://log.ometer.com/2003–11.html#16)
Just for
Jeff, improved blame assignment for memory hogging.
(This post was originally found at http://log.ometer.com/2003–11.html#16)
Screenshots
of the compositing manager prototype, also demoed live at the desktop
conference yesterday.
(This post was originally found at http://log.ometer.com/2003–11.html#11)
Fedora Core 1 is out (release
notes), and it rocks:
(This post was originally found at http://log.ometer.com/2003–11.html#5)
Does “open source community” mean the Slashdot horde and their PC
views, or the contributors who are building and supporting open source
software? People use the term without getting this distinction clear
in their minds.
(This post was originally found at http://log.ometer.com/2003–11.html#4.2)
Slashdot
readers… wow. Get your clues here:
Sigh. Yeah, I know I’m wasting my time. 😉
(This post was originally found at http://log.ometer.com/2003–11.html#4)
The freedesktop.org X hacking is
low-profile unstableware at the moment, but one particular proposal
interests me the most. Here is how I understand it, I’ll probably get
it wrong:
The idea is to make the X server model-view. The server stores a tree
of windows as it does now. However, unlike today, it keeps the full
contents of each mapped window in memory at all times. For each
window, the default view copies the window’s contents over the
contents of the parent window. This results in the same user-visible
display you have today — but you could implement alpha blended windows
by alpha compositing rather than copying each window into its parent,
since we now have the parent window’s contents.
To this we add the ability for a “compositing manager” to
replace the default view for a given window, using the aXe and XDamage
extensions. The window manager might be the compositing manager for
toplevel windows, for example.
If a window has a compositing manager, it will not be
composited into its parent automatically; the window is invisible
until the compositing manager does something. An external compositing
manager could emulate the default built-in compositing manager by
using XCopyArea() (or alpha-aware equivalent) to copy windows into
their parents.
However, a more exciting compositing manager might apply
embellishments/transformations to the window contents prior to drawing
them, possibly drawing them using an API such as OpenGL. For example,
you could add drop shadows. Or you could
do effects similar to fast
user switching or Expose. Or
you could double-buffer the entire screen as a whole making
workspace-switching, opaque resize, and other tasks flicker free. The
compositing manager is rendering a scene in which the window contents
are one element, so the possibilities are endless.
Note that the window contents stay entirely on the server side, the
compositing manager uses regular X protocol requests to manipulate
them.
Apps other than the single compositing manager can also use the damage
extension; possible applications include VNC (desktop sharing),
magnifiers, pagers with thumbnailing, and so forth. The compositing
manager is a special kind of view in that it disables the default
paint of the window to its parent, and is thus responsible for
replacing that default paint. But there can be any number of
extra views of a window.
There are a lot of little complexities and open questions here, but
the idea is pretty interesting. I’m waiting for something I can try
out to appear in jhbuild so I
can make metacity super-leet.
(This post was originally found at http://log.ometer.com/2003–11.html#3)
Seth: “Stop worrying
about ideas and get back to work” isn’t an accurate paraphrase.
I prefer: if you have an idea, do the work to make it happen. The
realistic path is probably twisty — having a goal in mind does not
imply a straight line to get there. Sometimes the work involves
writing code; sometimes it involves cat-herding or scrounging up
funding or writing a foundation charter or getting that next 1% of
marketshare.
Here is my vision: replace proprietary software for as many users as
possible. Without diving into details, I would argue that GNOME is
doing the right things to achieve this, most of the time. You’re
cooking up elaborate explanations where simple ones will do. Possibly
people are afraid and feel inadequate, or possibly they simply have a
realistic, incremental plan to grow the userbase. Possibly people are
risk-averse, and possibly the risks worth taking aren’t in the areas
you’re thinking of.
I would add one other thing, and that is: open source technology has
an inherent edge; its licensing and development model make it
better. This is Compelling Feature #1 for anything we produce. If it
weren’t, then really there’s no point; we’d just let Apple and
Microsoft have at each other.
The reality is that we have a good chunk of users ready to jump to
desktop Linux tomorrow despite its shortcomings, all we have to
do is fix the few barriers that make it impossible. And once we’ve
done that we’ll have more users, thus more developers, and we’ll be
free to focus 100% on the next step. Which could be anything someone
has the vision to guide us toward.
(This post was originally found at http://log.ometer.com/2003–10.html#30)
Seth: for every cool
thing that someone does, there were 100 people sitting around saying
“we should do something cool” 😉 Keep making it happen.
People forget too quickly how huge some of the battles were that made
GNOME what it is today. In my day, we didn’t have time-based releases
or basic UI sanity or HI guidelines, and we liked it. These things
that are orthodoxy today used to be heresy.
Look at Linux on the server: kernel 2.0 was a laughable toy, 2.6 is a
hugely scalable enterprise OS. But you don’t go straight to
enterprise OS. First somebody has to make the keyboard driver work.
First you have to get some customers and userbase. Then you have the
tools and the growth to take the next step.
The Apollo program had one luxury we don’t have, namely it was one of
the most amazing time and money sinks of all time. We have to evolve
such that each evolutionary step is usable and attracts more users
(and thus developers). Open source developers are attracted first and
foremost to working code that they’re using themselves. If cool were
everything, we’d all be hacking on Enlightenment.
Cool things happen via a thousand small, practical steps. It’s just
that you don’t usually notice these, unless you were the person taking
them.
And so the moral of the story is, while someone should make the X
server support smooth 3D graphics and implement the next generation of
UI on top of it (and in fact people are taking steps toward
that today), someone else should fix
the session manager so my splash screen doesn’t get stuck every
time I log in. You knew I was getting to that!
(This post was originally found at http://log.ometer.com/2003–10.html#29.2)
Speaking of copying Microsoft instead of innovating, should gnome-vfs
really be a UNIX-like interface to bytestreams, or should it be more,
say a general purpose data model with an
evolutionary upgrade path from the hierarchical filesystem and
features such as cross-machine
synchronization.
(This post was originally found at http://log.ometer.com/2003–10.html#29)
I’m well into Robert Love’s new book, Linux Kernel
Development. The book rocks; a concise, readable explanation of
all the major pieces of the kernel, how they work, how to use
them. Now if only I had time to apply this knowledge. 😉 Really I
just want to sound cool by using a lot of kernel jargon.
Question: if you wrote a similar guide to the implementation of the
desktop, how much longer would the book be? Define the desktop as say
“GNOME/OpenOffice.org/Mozilla/Evolution plus dependencies.” There’s
so much code involved.
If all this code together had a Linus-like global architect, what
would be different about the implementation? What’s the impact of
having dozens of separate projects coming together into a whole?
Intolerable Cruelty
was a lot of fun, reminded me of His Girl Friday.
(This post was originally found at http://log.ometer.com/2003–10.html#13)
