Merge lp://staging/~marmuta/onboard/nightmode into lp://staging/~onboard/onboard/main

Hi,
thank you for working on onboard! I'm really grateful that there is a well working onscreen keyboard installed by default in Ubuntu.

I've put some changes together to support a dark layout. The bright default layout was too straining on the eyes for my usage patterns, i.e. popping it open and closing it frequently on an otherwise dark desktop *squint*. Also I was switching panes way too frequently for editing and function keys.

There are two new layouts in the branch, both with an extended set of keys in the first pane, one in default colors and one meant for dark environments. Would there be any interest in merging this?

It'd be great if only the code changes made it in, as current onboard hard codes the label color to black, which effectively forbids the creation of dark layouts. I'd be absolutely thrilled if the layouts turned out to be merge material too though. They are the first thing I'm installing on a fresh system and frankly, there isn't that much choice in a default install of onboard yet.

Let me know what you think.

Hi Marmuta

Thanks for the contribution! I'm using the darkroom gtk theme and your colours fit much better than the default ones.

The proper fix would be for the default layout to get the colours from the current theme. That's a fair bit of work so this'll do for now.

I've got the following issues with the code, otherwise I'd be happy to merge:

The label_rgba field in the Pane class doesn't ever get used.

The label_rgba field in the KeyCommon class is a list but the docstring calls it a tuple. Also, I tend to shy away setting list default values in the class body. Variables defined in the class body are class variables, not instance variables. So key.label_rgba[0] = 0.5 for example, would set the red label_rgba value for every instance of KeyCommon. Either make the default value a tuple or set label_rgba = None and initialise to the default value in the __init__ method.

We're trying to standardise on underscore_seperated_variable_names not CamelCase and line lengths < 80 characters.

Hi,

Thanks Marmuta for your work.

I understand that you are not very satisfied with the default layout: in
fact, I am using a custom tailored layout myself; but I did not submit
it to the public, because it was a quick hack adding a line with the
keys I was missing on the main pain like the arrow keys, esc, del,
tilde, pipe,...

I gave a look at your layout and the following came to mind:

- The "Switch Buttons"-button is missing on your layout or did I
overlook it.

- Would it not be better to create a compact layout like those of a laptop?

- Concerning label_rgba: What about adding gconf keys for it as long as
we are not fetching them from the active theme? More, we might even
leave the gconf keys when we fetching them from the active theme adding
a "Back to default colors"-button setting the colors back to those
matching the theme.

Chris, could you please comment on my comments, especially the third
about label_rgba?

Cheers

Francesco

Chris Jones wrote:
> Review: Needs Fixing Hi Marmuta
>
> Thanks for the contribution! I'm using the darkroom gtk theme and
> your colours fit much better than the default ones.
>
> The proper fix would be for the default layout to get the colours
> from the current theme. That's a fair bit of work so this'll do for
> now.
>
> I've got the following issues with the code, otherwise I'd be happy
> to merge:
>
> The label_rgba field in the Pane class doesn't ever get used.
>
> The label_rgba field in the KeyCommon class is a list but the
> docstring calls it a tuple. Also, I tend to shy away setting list
> default values in the class body. Variables defined in the class
> body are class variables, not instance variables. So
> key.label_rgba[0] = 0.5 for example, would set the red label_rgba
> value for every instance of KeyCommon. Either make the default value
> a tuple or set label_rgba = None and initialise to the default value
> in the __init__ method.
>
> We're trying to standardise on underscore_seperated_variable_names
> not CamelCase and line lengths < 80 characters.

> Review: Needs Fixing
> Hi Marmuta
>
> Thanks for the contribution! I'm using the darkroom gtk theme and
> your colours fit much better than the default ones.
That's great, I'm glad you like it. I tend to use a pitch black
human theme, but now that I've seen it, it almost looks as if it
was made for darkroom :).

> The proper fix would be for the default layout to get the colours
> from the current theme. That's a fair bit of work so this'll do for
> now.
>
> I've got the following issues with the code, otherwise I'd be happy
> to merge:
>
> The label_rgba field in the Pane class doesn't ever get used.
Yeah, that is a bit awkward, but since the color is specified as an
attribute of the pane, I felt it should at least have a token
representation in the pane object. Actually I'd rather have used this
per-pane color directly for the label drawing than introduce a new
attribute label_rgba in class KeyCommon. Problem is, that the
containing pane is unknown for class RectKey and others. Is there a
reason that pane is not a member of the base class KeyCommon?

> The label_rgba field in the KeyCommon class is a list but the
> docstring calls it a tuple. Also, I tend to shy away setting list
> default values in the class body. Variables defined in the class
> body are class variables, not instance variables. So
> key.label_rgba[0] = 0.5 for example, would set the red label_rgba
> value for every instance of KeyCommon. Either make the default value
> a tuple or set label_rgba = None and initialise to the default value
> in the __init__ method.
Yes, thanks for pointing that out. It's a tuple now, though
I'd rather remove it altogether, see above.

> We're trying to standardise on underscore_seperated_variable_names
> not CamelCase and line lengths < 80 characters. --
Ok, done, I hope :)

> https://code.edge.launchpad.net/~marmuta/onboard/nightmode/+merge/12265
> You are the owner of lp:~marmuta/onboard/nightmode.

> Hi,
>
> Thanks Marmuta for your work.
Thank you, Francesco!

> I understand that you are not very satisfied with the default layout: in
> fact, I am using a custom tailored layout myself; but I did not submit
> it to the public, because it was a quick hack adding a line with the
> keys I was missing on the main pain like the arrow keys, esc, del,
> tilde, pipe,...
Yes, I had a hacked together one too for some time and finally decided to clean it up a bit :).

> I gave a look at your layout and the following came to mind:
>
> - The "Switch Buttons"-button is missing on your layout or did I
> overlook it.
Actually I didn't really understand what it was for, so it kinda dropped by the wayside.
Should it switch left and right pointer buttons? Is that to allow for right mouse clicks for single button pointer users? If yes, then should I perhaps move the settings button to the second pane and replaced it with "switch buttons"?

> - Would it not be better to create a compact layout like those of a laptop?
I found it easier for me to adapt when the virtual keyboard resembled the physical keyboard I'm most commonly using. It just happens to be the standard 105 key one for me. Compact layouts may be more efficient but they seem less standardized and come at the cost of a certain learning curve in the beginning. Not saying there shouldn't be more layouts to choose from though.

> - Concerning label_rgba: What about adding gconf keys for it as long as
> we are not fetching them from the active theme? More, we might even
> leave the gconf keys when we fetching them from the active theme adding
> a "Back to default colors"-button setting the colors back to those
> matching the theme.
I'm open for changes, the current solution simply seemed like the way of least resistance.

> Chris, could you please comment on my comments, especially the third
> about label_rgba?
>
> Cheers
>
> Francesco
>
>
> Chris Jones wrote:
> > Review: Needs Fixing Hi Marmuta
> >
> > Thanks for the contribution! I'm using the darkroom gtk theme and
> > your colours fit much better than the default ones.
> >
> > The proper fix would be for the default layout to get the colours
> > from the current theme. That's a fair bit of work so this'll do for
> > now.
> >
> > I've got the following issues with the code, otherwise I'd be happy
> > to merge:
> >
> > The label_rgba field in the Pane class doesn't ever get used.
> >
> > The label_rgba field in the KeyCommon class is a list but the
> > docstring calls it a tuple. Also, I tend to shy away setting list
> > default values in the class body. Variables defined in the class
> > body are class variables, not instance variables. So
> > key.label_rgba[0] = 0.5 for example, would set the red label_rgba
> > value for every instance of KeyCommon. Either make the default value
> > a tuple or set label_rgba = None and initialise to the default value
> > in the __init__ method.
> >
> > We're trying to standardise on underscore_seperated_variable_names
> > not CamelCase and line lengths < 80 characters.

Hi,

marmuta wrote:
>> - The "Switch Buttons"-button is missing on your layout or did I
>> overlook it.
> Actually I didn't really understand what it was for, so it kinda
> dropped by the wayside. Should it switch left and right pointer
> buttons? Is that to allow for right mouse clicks for single button
> pointer users? If yes, then should I perhaps move the settings button
> to the second pane and replaced it with "switch buttons"?

Yes; its function is indeed to switch left and right mouse buttons.

As the people with two mouse buttons don't have any use for it, I am not
sure if it is a good idea to put it on the main pane. It should however
be present on one of the panes, even if currently it is broken. Or does
the "Switch Button"-button work on your system?

(I just tried again by installing a .deb created from revision 179 of
trunk.)

>> - Would it not be better to create a compact layout like those of a
>> laptop?
> I found it easier for me to adapt when the virtual keyboard resembled
> the physical keyboard I'm most commonly using. It just happens to be
> the standard 105 key one for me. Compact layouts may be more
> efficient but they seem less standardized and come at the cost of a
> certain learning curve in the beginning. Not saying there shouldn't
> be more layouts to choose from though.

This turns into a tradeoff between screen space and user friendliness.
When Chris will have merged your changes to trunk after he finds them
ok, people will at least have the choice.

>> - Concerning label_rgba: What about adding gconf keys for it as
>> long as we are not fetching them from the active theme? More, we
>> might even leave the gconf keys when we fetching them from the
>> active theme adding a "Back to default colors"-button setting the
>> colors back to those matching the theme.
> I'm open for changes, the current solution simply seemed like the way
> of least resistance.
>
>> Chris, could you please comment on my comments, especially the
>> third about label_rgba?

Let's see what Chris is going to say about it...

Thanks again for your contribution.

Francesco

> Hi,
>
> marmuta wrote:
> >> - The "Switch Buttons"-button is missing on your layout or did I
> >> overlook it.
> > Actually I didn't really understand what it was for, so it kinda
> > dropped by the wayside. Should it switch left and right pointer
> > buttons? Is that to allow for right mouse clicks for single button
> > pointer users? If yes, then should I perhaps move the settings button
> > to the second pane and replaced it with "switch buttons"?
>
> Yes; its function is indeed to switch left and right mouse buttons.
>
> As the people with two mouse buttons don't have any use for it, I am not
> sure if it is a good idea to put it on the main pane. It should however
> be present on one of the panes, even if currently it is broken. Or does
> the "Switch Button"-button work on your system?
>
> (I just tried again by installing a .deb created from revision 179 of
> trunk.)

It is possible to fit in the switch buttons button by taking the full keyboard layout and swapping the settings and Prnt Scroll and Pause buttons. That leaves room to slot the switch buttons button underneath.

> > Compact layouts may be more
> > efficient but they seem less standardized and come at the cost of a
> > certain learning curve in the beginning. Not saying there shouldn't
> > be more layouts to choose from though.
>
> This turns into a tradeoff between screen space and user friendliness.
> When Chris will have merged your changes to trunk after he finds them
> ok, people will at least have the choice.

It's probably worth sticking to the standard layout as much as possible. We can always provide a compact layout as another option.

> >> - Concerning label_rgba: What about adding gconf keys for it as
> >> long as we are not fetching them from the active theme? More, we
> >> might even leave the gconf keys when we fetching them from the
> >> active theme adding a "Back to default colors"-button setting the
> >> colors back to those matching the theme.
> > I'm open for changes, the current solution simply seemed like the way
> > of least resistance.

I don't think that many people will want to change the label colours without also changing the colours of the keys themselves. I think it's worth allowing users to change theme colours without using a text editor. Something along the lines of gnome-appearance-properties' customise theme colours dialog.

> > The label_rgba field in the Pane class doesn't ever get used.
> Yeah, that is a bit awkward, but since the color is specified as an
> attribute of the pane, I felt it should at least have a token
> representation in the pane object.

I think the key itself should hold the label colour. It would be worth adding the ability to specify label colours per key in addition to per pane. With the key label colours taking precedence over the pane label colours.

> Actually I'd rather have used this
> per-pane color directly for the label drawing than introduce a new
> attribute label_rgba in class KeyCommon. Problem is, that the
> containing pane is unknown for class RectKey and others. Is there a
> reason that pane is not a member of the base class KeyCommon?

I've been trying to avoid circular references, it can make the code a bit messy.

Remove Pane.label_rgba and I'll merge the code changes :-)

Hi,

Chris Jones wrote:
>> marmuta wrote:
>> As the people with two mouse buttons don't have any use for it, I
>> am not sure if it is a good idea to put it on the main pane. It
>> should however be present on one of the panes, even if currently it
>> is broken. Or does the "Switch Button"-button work on your system?
>>
>> (I just tried again by installing a .deb created from revision 179
>> of trunk.)
>
> It is possible to fit in the switch buttons button by taking the full
> keyboard layout and swapping the settings and Prnt Scroll and Pause
> buttons. That leaves room to slot the switch buttons button
> underneath.

I don't think that the Print, Scroll and Pause buttons will fit in a
space where the Settings button is currently positioned. What about the
following:

As there is an empty line over the arrows, why not move down the 9
buttons placed over the arrow keys to free the space to the right of the
function keys. This will give us plenty of space for the
"Settings"-button and "Switch Buttons"-buttons.

That would also be room for an "Iconize"-button, that I have to mind for
some time yet. In fact, the idea is to create such an "Iconize"-button
to have a bigger target than the button on the title bar, to the
minimize onboard to the panel (or to the floating icon if it is active).
Since we are talking about layout, I thought to mention it, but until
now I have not looked at how it could be implemented.

>>> Compact layouts may be more efficient but they seem less
>>> standardized and come at the cost of a certain learning curve in
>>> the beginning. Not saying there shouldn't be more layouts to
>>> choose from though.
>> This turns into a tradeoff between screen space and user
>> friendliness. When Chris will have merged your changes to trunk
>> after he finds them ok, people will at least have the choice.
>
> It's probably worth sticking to the standard layout as much as
> possible. We can always provide a compact layout as another option.

ok

>>>> - Concerning label_rgba: What about adding gconf keys for it as
>>>> long as we are not fetching them from the active theme? More,
>>>> we might even leave the gconf keys when we fetching them from
>>>> the active theme adding a "Back to default colors"-button
>>>> setting the colors back to those matching the theme.
>>> I'm open for changes, the current solution simply seemed like the
>>> way of least resistance.
>
> I don't think that many people will want to change the label colours
> without also changing the colours of the keys themselves. I think
> it's worth allowing users to change theme colours without using a
> text editor. Something along the lines of
> gnome-appearance-properties' customise theme colours dialog.

Yes, something along the lines of the colors dialog in
gnome-appearance-properties. But I would say to leave that for onboard
0.93, as the changes will not be trivial; or am I wrong?

Cheers

Francesco

Hi,

I've added sorting for the layout list in settings to get the default
layout back to the top. If that's not wanted please just ignore it for the merge.

> marmuta wrote:
> >> - The "Switch Buttons"-button is missing on your layout or did I
> >> overlook it.
> > Actually I didn't really understand what it was for, so it kinda
> > dropped by the wayside. Should it switch left and right pointer
> > buttons? Is that to allow for right mouse clicks for single button
> > pointer users? If yes, then should I perhaps move the settings
> > button to the second pane and replaced it with "switch buttons"?
>
> Yes; its function is indeed to switch left and right mouse buttons.
>
> As the people with two mouse buttons don't have any use for it, I am
> not sure if it is a good idea to put it on the main pane. It should
> however be present on one of the panes, even if currently it is
> broken.
I had it added to the second panes yesterday, close to the tab bar to
keep the travel distance low, but I see that the discussion is
ongoing :)

> Or does the "Switch Button"-button work on your system?
Unfortunately not, it toggles the gconf key without the switch happening. It doesn't work from gconf-editor either, only from gnome-mouse-properties for some reason.

> > It is possible to fit in the switch buttons button by taking the
> > full keyboard layout and swapping the settings and Prnt Scroll and
> > Pause buttons. That leaves room to slot the switch buttons button
> > underneath.
>
> I don't think that the Print, Scroll and Pause buttons will fit in a
> space where the Settings button is currently positioned. What about
> the following:
>
> As there is an empty line over the arrows, why not move down the 9
> buttons placed over the arrow keys to free the space to the right of
> the function keys. This will give us plenty of space for the
> "Settings"-button and "Switch Buttons"-buttons.
That would make me hunt for keys again for a while. My
motivation was originally to have a close representation of the
standard keyboard to avoid having to retrain when switching between
on- and off-screen keyboards across operations systems. They are all
different in gnome, kde and the other OS already, each with its
own incompatible trade-offs.

Would it be wrong to demote the settings button to the second pane? I do kinda like it where it is, but it's not really an input button and "switch buttons" seems more important. There are already two other ways to get to the settings too, plus I'd expect settings to be used only occasionally.

Here is another spacy idea, though somewhat beyond the scope of this merge. Instead of a switch button have three, perhaps round buttons for double click, middle- and right mouse button, (D) (M) (R). They would fit into the empty space above the cursor keys. All three would act three-state sticky like the other modifier keys. That would allow for left-, middle-, right-, both single- and double click and the keyboard layout wouldn't need to be shifted around.
There could be a toggle in settings to turn pointer keys on/off too.

> > > The label_rgba field in the Pane class doesn't ever get used.
> > Yeah, that is a bit awkward, but since the color is specified as an
> > attribute of the pane, I felt it should at least have a token
> > representation in the pane object.
>
> I think the key itself should hold the label colour. It would be
> worth adding the ability to specify label colours per key in addition
> to per pane. With the key label colours taking precedence over the
> pane label colours.
That was the intention after the pane turned out to be inaccessible.
On the other hand physical keyboard rarely come with different colored
key labels either.

> > Actually I'd rather have used this
> > per-pane color directly for the label drawing than introduce a new
> > attribute label_rgba in class KeyCommon. Problem is, that the
> > containing pane is unknown for class RectKey and others. Is there a
> > reason that pane is not a member of the base class KeyCommon?
>
> I've been trying to avoid circular references, it can make the code a
> bit messy.
>
> Remove Pane.label_rgba and I'll merge the code changes :-)
OK, it's gone :)

Hi,

marmuta wrote:
> I've added sorting for the layout list in settings to get the default
> layout back to the top. If that's not wanted please just ignore it
> for the merge.

It is ok for me; but it is up to Chris to decide.

>> As the people with two mouse buttons don't have any use for it, I
>> am not sure if it is a good idea to put it on the main pane. It
>> should however be present on one of the panes, even if currently it
>> is broken.
> I had it added to the second panes yesterday, close to the tab bar to
> keep the travel distance low, but I see that the discussion is
> ongoing :)

This is also ok for me.

>> Or does the "Switch Button"-button work on your system?
> Unfortunately not, it toggles the gconf key without the switch
> happening. It doesn't work from gconf-editor either, only from
> gnome-mouse-properties for some reason.

The same is happening on my system; so it seems to be a problem of
karmic and not a quirk of my system. And as it also does not work from
gconf-editor, we can assume that it is not fault of onboard.

>>> It is possible to fit in the switch buttons button by taking the
>>> full keyboard layout and swapping the settings and Prnt Scroll
>>> and Pause buttons. That leaves room to slot the switch buttons
>>> button underneath.
>> I don't think that the Print, Scroll and Pause buttons will fit in
>> a space where the Settings button is currently positioned. What
>> about the following:
>>
>> As there is an empty line over the arrows, why not move down the 9
>> buttons placed over the arrow keys to free the space to the right
>> of the function keys. This will give us plenty of space for the
>> "Settings"-button and "Switch Buttons"-buttons.
> That would make me hunt for keys again for a while. My motivation was
> originally to have a close representation of the standard keyboard
> to avoid having to retrain when switching between on- and off-screen
> keyboards across operations systems. They are all different in gnome,
> kde and the other OS already, each with its own incompatible
> trade-offs.

My suggestion about moving the 9 keys down one row was mainly to get
enough space for the Settings and Switch Buttons buttons.

> Would it be wrong to demote the settings button to the second pane? I
> do kinda like it where it is, but it's not really an input button
> and "switch buttons" seems more important. There are already two
> other ways to get to the settings too, plus I'd expect settings to be
> used only occasionally.

Indeed, once a user has congigured onboard the way he likes it, he will
only rarely use the Settings button. Consequently, I also think that it
would be better suited on the second pane.

Concerning the Switch Buttons button, we should probably also put it on
the second pane, because:
- people able to use two mouse buttons don't have any usage for it
- people that can only use one mouse button already have an alternative
in the Accessibility tab of the mouse control panel

However, there are situations where the alternative does not work
because of the way it has been implemented. For the moment, these users
have to resort to dwell clicking (also in the acces...

>
> >> As the people with two mouse buttons don't have any use for it, I
> >> am not sure if it is a good idea to put it on the main pane. It
> >> should however be present on one of the panes, even if currently it
> >> is broken.
> > I had it added to the second panes yesterday, close to the tab bar
> > to keep the travel distance low, but I see that the discussion is
> > ongoing :)
>
> This is also ok for me.
>
Right, so "switch buttons" stays on the second pane.

> >>
> >> As there is an empty line over the arrows, why not move down the 9
> >> buttons placed over the arrow keys to free the space to the right
> >> of the function keys. This will give us plenty of space for the
> >> "Settings"-button and "Switch Buttons"-buttons.
> > That would make me hunt for keys again for a while. My motivation
> > was originally to have a close representation of the standard
> > keyboard to avoid having to retrain when switching between on- and
> > off-screen keyboards across operations systems. They are all
> > different in gnome, kde and the other OS already, each with its own
> > incompatible trade-offs.
>
> My suggestion about moving the 9 keys down one row was mainly to get
> enough space for the Settings and Switch Buttons buttons.

Yes, this is how I understood it. I was trying to argue against that
change and for sacrificing the settings button instead, but...

> > Would it be wrong to demote the settings button to the second pane?
> > I do kinda like it where it is, but it's not really an input button
> > and "switch buttons" seems more important. There are already two
> > other ways to get to the settings too, plus I'd expect settings to
> > be used only occasionally.
>
> Indeed, once a user has congigured onboard the way he likes it, he
> will only rarely use the Settings button. Consequently, I also think
> that it would be better suited on the second pane.

...now that "switch buttons" stays in the second pane there is no pressing need to move settings anymore, right? So keep the layout in its current state with settings first pane, switch buttons second?
Chris, would that be acceptable for you too?

> Concerning the Switch Buttons button, we should probably also put it
> on the second pane, because:
> - people able to use two mouse buttons don't have any usage for it
> - people that can only use one mouse button already have an
> alternative in the Accessibility tab of the mouse control panel

OK, "switch buttons" stays on the second pane.

> > Here is another spacy idea, though somewhat beyond the scope of
> > this merge. Instead of a switch button have three, perhaps round
> > buttons for double click, middle- and right mouse button, (D) (M)
> > (R). They would fit into the empty space above the cursor keys. All
> > three would act three-state sticky like the other modifier keys.
> > That would allow for left-, middle-, right-, both single- and
> > double click and the keyboard layout wouldn't need to be shifted
> > around. There could be a toggle in settings to turn pointer keys
> > on/off too.
>
> Adding such a functionality would probably make onboard depend on the
> AT-SPI framework.

If so, than I take m...

> As there is an empty line over the arrows, why not move down the 9
> buttons placed over the arrow keys to free the space to the right of the
> function keys. This will give us plenty of space for the
> "Settings"-button and "Switch Buttons"-buttons.

Yeah, that's what I meant :-)

>
> That would also be room for an "Iconize"-button, that I have to mind for
> some time yet. In fact, the idea is to create such an "Iconize"-button
> to have a bigger target than the button on the title bar, to the
> minimize onboard to the panel (or to the floating icon if it is active).
> Since we are talking about layout, I thought to mention it, but until
> now I have not looked at how it could be implemented.

Good idea. Maybe extend the script key action so that scripts are passed an instance of the running keyboard that they can act on.

> Yes, something along the lines of the colors dialog in
> gnome-appearance-properties. But I would say to leave that for onboard
> 0.93, as the changes will not be trivial; or am I wrong?

Yes, lets leave that for 0.93.

Cheers, Chris

Hi,

Chris Jones wrote:
>> That would also be room for an "Iconize"-button, that I have to
>> mind for some time yet. In fact, the idea is to create such an
>> "Iconize"-button to have a bigger target than the button on the
>> title bar, to the minimize onboard to the panel (or to the floating
>> icon if it is active). Since we are talking about layout, I thought
>> to mention it, but until now I have not looked at how it could be
>> implemented.
>
> Good idea. Maybe extend the script key action so that scripts are
> passed an instance of the running keyboard that they can act on.

I would say to also leave this for version 0.93, otherwise we will never
get to the 0.92 release...

Or if it is trivial for you to add it, I would use the space of the
Settings button of the Full layout for the Iconize-button, and put the
Settings button and the Switch Buttons button to the second pane.

Cheers

Francesco

> ...now that "switch buttons" stays in the second pane there is no pressing
> need to move settings anymore, right? So keep the layout in its current state
> with settings first pane, switch buttons second?
> Chris, would that be acceptable for you too?

Yep

> If so, than I take my proposal back :) I'd rather not have onboard require
> "Assistive Technologies". Back when I was dwell clicking for a while, I was
> looking for simple tools. Mousetweaks for some reason needs the whole AT-SPI
> framework enabled, with high memory usage, slower applications and the
> occasional crashers. I gave up on it and settled on kmousetool instead. Things
> may have changed though, I haven't needed it in a while.
>
> > Moreover, would such a functionality not be better suited in the
> > mousetweaks module that is already providing the features of the
> > accessibility tab of the mouse control panel?
>
> That's true, on second thought reimplementing half of mousetweaks features
> doesn't seem like a sensible thing to do.

Currently the switch buttons button toggles a gconf key which is monitored by gnome-settings-daemon. This works inconsistently on my system. Since gnome-settings-daemon does not depend on AT-SPI it must be possible to mangle mouse buttons without it.

I think this functionality probably doesn't belong in Onboard. Mousetweaks seems to use AT-SPI to get a global pointer location. It's hard to understand why the at-spi-registryd is needed for that information.

Ok, I think we're ready to merge now :-)

Hi,

Chris Jones wrote:
>> If so, than I take my proposal back :) I'd rather not have onboard
>> require "Assistive Technologies". Back when I was dwell clicking
>> for a while, I was looking for simple tools. Mousetweaks for some
>> reason needs the whole AT-SPI framework enabled, with high memory
>> usage, slower applications and the occasional crashers. I gave up
>> on it and settled on kmousetool instead. Things may have changed
>> though, I haven't needed it in a while.
>>
>>> Moreover, would such a functionality not be better suited in the
>>> mousetweaks module that is already providing the features of the
>>> accessibility tab of the mouse control panel?
>> That's true, on second thought reimplementing half of mousetweaks
>> features doesn't seem like a sensible thing to do.
>
> Currently the switch buttons button toggles a gconf key which is
> monitored by gnome-settings-daemon. This works inconsistently on my
> system. Since gnome-settings-daemon does not depend on AT-SPI it
> must be possible to mangle mouse buttons without it.
>
> I think this functionality probably doesn't belong in Onboard.
> Mousetweaks seems to use AT-SPI to get a global pointer location.
> It's hard to understand why the at-spi-registryd is needed for that
> information.

Indeed, toggling left and right handedness of the pointer does not need
at-spi, but I suppose that if we wanted to perform more advanced
manipulations on the mouse clicks, we would have to use AT-SPI.

Anyway, we surely agree on the fact that there are other functionalities
(like word completion and word prediction) that deserve more our
attention to be implemented in onboard than mouse click manipulations.

Cheers

Francesco