auspex is currently certified at Journeyer level.

Name: Gregory Merchan
Member since: 2000-10-30 16:48:08
Last Login: 2014-04-07 01:00:52

FOAF RDF Share This

Notes:

None yet.

Recent blog entries by auspex

Syndication: RSS 2.0

pfh, don't forget simple masochism.

As for humour as a mode of thought: I wish I could be all dramatically "Woe is me!" depressed. Instead I find humour in all manner of things and laugh all too frequently. "How's it going?" I'm asked, and, "Absolutely miserably!" I smilingly respond. But that doesn't actually improve my mood or lift me far enough out of depression to do what I used to want to do, so . . . it's a bit depressing. (Ha!) I was a clown for a day - perhaps I should try to get paid to be one again.

Given the number of blogs wherein personal psychic problems are made public, I hope psychologists, psychiatrists, and sociologists are paying attention. That diaries, which used to be kept under lock, are now for public consumption is interesting in itself. I wonder how this is connected to the rash of "reality tv".

XUL Desktop Environment? I think it's almost possible, but I wish I knew how to start filling some gaps. These problems are present on at least the X11 (gtk2) backend.

  • Windows always accept focus. (Gtk2 also has this problem for the most part.) Some windows, such as an on-screen keyboard window, should never accept focus. (Gtk2 allows such behavior.)

    Other windows should only accept focus when it's is assigned by keyboard - to allow keyboard access. A simple palette with a grid of buttons, similar to the GIMP's, shouldn't accept focus because it functions as an auxilliary to a document. The user should be able to click a palette button and continue working on the document without having to move focus back to the document - just as if he had clicked on a toolbar in the document window. The gtk2 backend of XUL will not allow this, even if XUL does.

    Most windows should not accept focus if the user is merely dragging something from the window to another window, neither should they be raised in such a case. Windows Explorer and perhaps MacOS Finder exhibit this behavior. Nautilus was supposed to, but won't until Gtk2 and Metacity are fixed.

    Some windows, such as the GNOME panel, should perhaps exhibit a mix of these behaviors. Should the click fall in the text field of an applet, focus is needed. Otherwise, it should be refused.

  • Timestamps are very important for X11, and perhaps nothing else. They are needed to control focus, grabs, and selections. These needs push the need for timestamps down to the execution environment where they can be made available directly or by reference as in the freedesktop.org startup-notification-spec. While the need for timestamps can be almost surely be hidden behind a toolkit's abstractions, it is still an extra burden for building on X11 instead of Windows or MacOS.
  • The importance of the window manager has been greatly exaggerated. The window manager is needed to control some stacking, to sometimes control focus, and for some global operations like Alt+Tab window switching. "Decorations", as window frame controls are misnamed, would perhaps be better left to the toolkit. (Supposedly there's an implementation problem with that, but I won't believe so until I've seen it. My experiments reveal no such problem.)

    The stack control needed is minimal. Some windows should always be below others, and some windows should always be above others. Otherwise, the focused window should not be obscured when a new normal window is mapped.

    Focus control, if the frame is part of the toolkit window, is only needed when focus falls to the root window. Except for the next part...

    Global operations can't be left to the toolkit; or, at least I haven't thought of a way to do that yet. Consider Alt+Tab. For this to work as most people expect it to, the program that process the keystroke needs to know which windows to include in the chain, the order to include them, their names and icons. There are ways to do this without a window manager, but they're probably too slow and certainly too messy. Since the window manager is the best thing to handle this, it also needs to assign focus once the user selects a window. Until FocusChangeEvent can be extended to include a time and previous window, the best mechanism for this is the WM_TAKE_FOCUS message.

  • There's no fine control over whether the first click in an unfocused window does something. Sometimes it should and sometimes it shouldn't, but things are not currently done in a way that a program can reliably determine whether a click was part of a focus transfer or not. This is easily fixed in the same way focus handling is fixed.

The changes I have in mind are really simple if you ignore legacy applications. A migration scheme doesn't seem to hard either, except that I can't convince anyone the destination is worth reaching. So I've been toying with two ideas:

  • Write a toolkit and WM to make it happen. I wrote the core of the no-legacy-support WM over a month ago; after all, that's only a few K. Then I started toying with making a toolkit. Ha! The possibility of using Cairo has been very distracting. Most distracting though is looking at other toolkits and thinking, "maybe I could convice these guys to make a few changes instead." Lately, XUL is most appealing.
  • Give up.

I consider why I might do this and find no good reason. Every reason I can think of is neurotic. (I'll not list them.) I miss enjoying the study of physics. (I never got far enough to enjoy the study of nature as a physicist.) I miss enjoying study and I think I've been missing that for a long time. I laugh when I think puberty may have been to blame. I laugh a lot for someone so depressed, and it's not just a nervous reaction. This and more often mislead people. I wonder, but mostly doubt, whether I can still read French. Mr. Hugo might have a book for me. Perhaps I'll watch the movie first.

11 Apr 2004 (updated 11 Apr 2004 at 00:08 UTC) »
AlanHorkan,
A misanthrope hates mankind, which includes women. A misandrist hates men - i.e., male humans. See also misandry, for which you don't need a subscription.

Raiseless DnD

Filed many bugs this past weekend to get raiseless DnD support in GNOME, and grouped them with a meta-bug. I split them too finely, so Owen promptly marked some as duplicates of others. All the Gtk+ bugs are on the 2.6 API freeze target milestone. Thanks to some earlier work and Matthias Clasen, there's already a patch which makes most of the necessary changes to Gtk+. The Metacity bugs have patches attached too, though they're the minimum needed (three lines) to get the right behavior and less than ideal.

30 Jan 2004 (updated 1 Feb 2004 at 02:43 UTC) »

A few hours ago, I discovered another way to make X window managers and applications so that the beginning of a drag does not raise the drag-source window. This method is even simpler than the method I wrote about in October.

That old method worked well and I had demos on my website for a short time. While writing to gnome-accessibility-list to request an assessment of the method's accessibility impact, I discovered the simpler method. (And cancelled the suddenly obsolete message.) The old method also made it easy to eliminate other problems. The new one eliminates even more problems.

Neither method introduces a new protocol. They both rely on what's in the ICCCM and judicious window management policies.

The ICCCM revision history seems to indicate that both methods have been possible since 1989, when ICCCM version 1.0 was released.

Is it better to be the first person to realize this than not? If I'm the first, then everyone else has missed the solution. If I'm not the first, then somebody else has been either silent or unduly ignored. It would have been better to not have considered the question.

63 older entries...

 

auspex certified others as follows:

  • auspex certified feyd as Apprentice
  • auspex certified Kenny as Apprentice
  • auspex certified julian as Journeyer
  • auspex certified vicious as Journeyer
  • auspex certified jdub as Apprentice
  • auspex certified alan as Master
  • auspex certified jwz as Master
  • auspex certified rms as Master
  • auspex certified cbbrowne as Journeyer
  • auspex certified hudson as Master

Others have certified auspex as follows:

  • Kenny certified auspex as Apprentice
  • strlen certified auspex as Journeyer
  • ztf certified auspex as Journeyer
  • jdub certified auspex as Apprentice
  • julian certified auspex as Journeyer
  • lerdsuwa certified auspex as Apprentice
  • MikeGTN certified auspex as Apprentice
  • andersca certified auspex as Apprentice
  • Uraeus certified auspex as Journeyer
  • aldug certified auspex as Journeyer
  • gleblanc certified auspex as Journeyer
  • menthos certified auspex as Journeyer
  • realblades certified auspex as Journeyer
  • pencechp certified auspex as Apprentice
  • funrecords certified auspex as Journeyer
  • Stevey certified auspex as Apprentice
  • clarkbw certified auspex as Journeyer
  • dlc certified auspex as Journeyer
  • ataridatacenter certified auspex as Journeyer
  • mhamilton certified auspex as Journeyer

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page