Re: Mouse a11y tab



On 12.11.2007 17:17, Gerd Kohlberger wrote:
Jens Granseuer wrote:
> On 10.11.2007 21:36, Francesco Fumanti wrote:
> I like Denis' version better, but that may just be
> me. In any case, the tab layout needs to be integrated
> in the glade mockup, so which of the two we start from
> doesn't matter terribly much.

I'm fine with using Denis' version. The important things is that
mt won't work (correctly) without  the 2 missing options.  (threshold
and 'Show click type window')

Sure, no problem adding those.

>> In layout [1], the ignore little movements slider is missing.
>
> Isn't that what the standard X sensitivity (threshold)
> option does? Do we need it twice? What's the
> difference?

The threshold option is used for dwell clicks. Dwelling triggers a click
after the pointer stays at the same screen position for a some time.
Some people
might have difficulty keeping the pointer completely motionless for that
time.
eg. users with eye tracking hardware.

Ok, makes sense.

>> - Mousetweaks is still in the module proposal process; could this be
>> a problem?
>
> No. If we (g-c-c maintainers) and you (MT devs) agree that
> MouseTweaks should not be a separate module, but included
> in g-c-c, then basically your proposal is moot, and we'll
> just add MouseTweaks integration as an item on the g-c-c
> roadmap for 2.22.
I would actually prefer mousetweaks becoming a standalone module.

Transforming the mt daemon in a settings module isn't going to work, because
they are all compiled into one binary. This, I guess, makes it
impossible to use
mousetweaks in GDM.  If the daemon stays in its own binary then there is no
reason to move it inside the gnome-cc tree.

Well, yes and no. I agree that the GDM case may well be a problem.
I don't know the a11y stuff very well, though. The a11y daemon is
also started only after logging in, isn't it? How do they solve the
GDM issue? (Do they just ignore it? If so, should we, too?)

Jens, maybe you can explain a bit more how a full integration in
gnome-cc would look like.

Full integration in my mind would be:

* MT settings in mouse capplet (you're probably not getting around that
  anyway. A new capplet is a no-no.)

* MT daemon as a g-s-d module. If (!) GDM turns out to be a problem
  serious enough to keep a separate daemon, you're probably going to
  need some g-s-d integration anyway (starting/stopping the daemon
  when the options are changed). But yes, in that case the daemon
  (and only the daemon) might make sense as a separate package, too.
  I must admit I'm not too fond of the prospect of yet another daemon,
  though.

Jens


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]