On Fri, 10 Mar 2000, Greg Ward wrote:
> OK, I'll buy the WM argument for positioning (but I still dislike it).
> But what about focus? I gather that forcibly moving focus around is
> generally frowned upon in the X world, but this is *really stupid*.
> When I'm typing in a filename and make a mistake, then I should be able
> to dismiss the error dialog with a quick tap of the space-bar or Enter
> key -- as it is, I have to fumble for my mouse, grope around the screen
> trying to get the pointer in the window, and then stumble my way to the
> "Ok" button to click it (or go *back* to the keyboard, hammer on the
> space-bar, remember that that's a Tk thing and not a GTK thing, and then
> hit Enter -- ARGGHHH!!!)
Once again, this is really a window manager issue -- it is responsible for
keyboard focus handling. For sawmill, I can create a window match for
certain windows and say that they should get focus when mapped (shown),
which seems to be what you want (I just started using sawmill a few weeks
ago, and it is great :)
>
> Remember, one of the other long-established conventions in the X world
> is focus-follows-mouse-down-to-the-widget-level, which is utterly,
> colossally, mind-bogglingly STUPID and contributes to the worst user
> interface conceivable, namely that of any Athena-based program ever
> written. Anyways, I'm ranting again -- I'll shut up before I embarass
> myself.
Most toolkits used for applications do not use focus follows mouse for
individual widget focus, so this is not really an issue.
> Sounds like the consensus is that a menubar should be optional. I would
> argue that it should be the default, since 15-20 years of GUIs have
> ingrained in users the notion that menus are at the top of the window.
> (Well, except for Mac users. Whatever.)
How about getting it so that tearoff menus work correctly. What this
means is that you should be able to tear off the menu from one diagram,
start working on another diagram, and the menu items will now effect the
current diagram. This is sort of like next menus, which could be
considered the successor of the apple menu bar (and is a lot better when
running in high res).
>
> > > * no visible rubber-band when dragging to select objects
> >
> > Huh? I see a nice dashed rubber-band.
>
> Hmmm, seems to be a portability problem. So far I've been using Dia on
> a Solaris 2.6 box. When I run it and display it on that Solaris box, I
> get no rubber-band when dragging to select. When I run it on the
> Solaris box and display it on the Linux machine on the other side of my
> desk, it works just fine. What else could be different but the X server
> involved? (I haven't yet built Dia for Linux.) How strange. If you
> have any ideas about figuring this one out (X extensions to look for,
> different Solaris versions or patches, ...?), I'd like to hear 'em!
Dia just uses the XOR graphics context function. I don't know why it
would have trouble on a Sun.
> I'll see what I can do. There are a lot more small-but-annoying
> problems with Dia's user interface than what I was able to come up with
> the other day. (I've been reading books on usability lately, so I no
> longer have any patience for clunky user interfaces. I will do my best
> to be a royal pain in the ass to the Dia developers, because I think in
> the long run it will help.)
>
> Greg
James.
