Re: [gtk-list] Re: My experiences with GTK - what I would like changed...
- From: "GTK.Mailinglist.account" <gtk-ml fusebox hanse de>
- To: gtk-outgoing fusebox hanse de
- Subject: Re: [gtk-list] Re: My experiences with GTK - what I would like changed...
- Date: 02 Jun 1998 00:38:05 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Elliot Lee <sopwith@redhat.com> writes:
> On 1 Jun 1998, GTK.Mailinglist.account wrote:
> > - - The GTK+ seems to follow a "click-to-focus" strategy even if the
> > window manager (and hence all other applications)
> (I don't follow that last connection - applications are entirely free to
> set the focus on widgets according to toolkit policies, not by what the wm
> does. wm focus mode only affects focus among toplevels).
> > follow a "focus-follows-mouse" one. This is kinda annoying, because I
> > need to click on a button, leave the window again (because otherwise it
> > won't acknowledge the focus)
> Do you have your wm set in ClickToFocus mode and it is not passing through
> the first click?
My wm is set to "focus-follows-mouse" - so you'd think I should be able
to select a button without having to click on the window and reenter
it once.
> It's just that I'm not understanding this "leave the window again" part -
> I know I can just click on a button and it does the action, whether or not
> that window is in focus.
You can either click on it about 20 times or click on it, move the
mouse a bit and then you can select it. I have heard from amost
everyone else that they made the same experiences on their system (all
Linux systems with fvwm2).
> > and then I can use the button. I think this is the biggest flaw of GTK
> > "feel-wise".
> Only problem with FocusFollowsMouse is that it forces you to use the mouse
> more or less. I prefer to have the keyboard be giving the authoritative
> commands, and the mouse filling in when the keyboard doesn't fit the bill.
Well - that should be up to the user... but having one window that
insists on click to focus whereas everything else is
focus-follows-mouse is kinda annoying.
> > This could easily by done by a GList, I guess... and it would make
> > object oriented programming even easier.
> It's already in there! :) Read gtkobject.h, especially the section about
> set_*data and get_*data routines.
Thanks to everyone who answered. The function is actually better than
I hoped. Extremely cool for object oriented programming !!!
> > - - The last big thing I have been looking and couldn't find was a
> > signal handler where I can have a routine being called when a child
> > dies or sends any other signal. I know I could probably do that by
> > directly using the systems handlers, but it would be much better to
> > only have GTK managing this kind of stuff.
> Adding a gtk layer on top of signals wouldn't give any advantage that I
> can think of - there really isn't very much to sigaction.
Well - I am only used to XVIEW... there it is strictly forbidden to
directly use the system-layered signal handlers. They say that since
the X client-server communication has some timing-critical moments an
interrupt in the program at the wrong moment could disrupt it and have
bad consequences. If the toolkit does the distribution it can be sure
nothing happens at the wrong moment.
Personally I think the reasoning makes some sense, so I asked myself
whether this signal handling will be implemented in the near future.
On the other hand: Has anyone made any experiences (positive or
negative) with using the handlers directly ? I'd ne kinda interested
to hear about it...
Later,
Georg
- --
Georg C. F. Greve <greve@fusebox.hanse.de>
http://porter.desy.de/~greve/ - ICQ#10016966
"People who fight may lose. People who do not
fight have already lost." -- Bertolt Brecht
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed
iQCVAwUBNXMtTVZXgZXDxqJtAQHbBQP9El7HDNTBz1SCHWdKXEO/18mhOLu2e+/j
58m/igVhMuQiAvdPzE20fQYZz7I2Q4FEnlPQNsplDMC0zecolBILUNgc8eaB8Zpb
gnjcvqJh1ZU3+CrIz3Qak1UMTd/p+H0i48LHOK/zjUrKu/u8siZ0Vt2K0bvEnmfy
oiYWESr93L4=
=2mPI
-----END PGP SIGNATURE-----
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]