Questions I have:

 - What would be the best label to use for the switch button?
   Would "Enable Tablet PC mode" be appropriate or is that too vague?

 - Would that control be available to screen tablets only or any tablet?
   While "Tablet PC" are screen tablets, this option might be of interest for
   regular non-screen tablets as well.

We had to discuss this for 10 minutes before I got a vague idea what the stylus button mode is about. I really would like to hear the use case for the button behavior you/wacom driver calls Tablet PC mode. I don't have an answer to the second question before I understand its existence.

Created attachment 226442 [details] [review]
Patch to add a mode "auto" to leave the option untouched by g-c-c

Quite a few discussion occurred in the downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=855294

It is said the the driver knows best when to enable/disable Tablet PC mode [1], yet it appears that exposing such an option in the UI is not suitable [2].

To achieve this, the "tablet-pc-button" setting needs a 3rd option so it's changed from type boolean to enum, with "auto", "on" or "off"·

When mode is "auto" (default), the setting is left completely untouched, ie whatever is set by the driver initially remains.

Note, switching from "on" of "off" will _not_ reset to the driver default (since it's lost), "auto" works only before the option is changed either manually on by "g-s-d".

Would a patch be acceptable?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=855294#c6
[2] https://bugzilla.redhat.com/show_bug.cgi?id=855294#c7

Why is this an option at all if the driver knows better? (better than the user even?)

Some user may want to change it (ie we would leave the driver decide unless the user changes the options).

That would be in g-s-d rather and no UI option (so this bug would move to g-s-d instead - the patch is actually for g-s-d, sorry).

(In reply to comment #5)
> Some user may want to change it (ie we would leave the driver decide unless the
> user changes the options).

Just how many users would do that?

> That would be in g-s-d rather and no UI option (so this bug would move to g-s-d
> instead - the patch is actually for g-s-d, sorry).

I would add support for org.gnome.settings-daemon.peripherals.input-devices hotplug-command to the wacom plugin, and let people call xinput by hand if they really wanted to change the tablet pc property (and remove the tablet pc property from the wacom schemas)

(In reply to comment #6)
> (In reply to comment #5)
> > Some user may want to change it (ie we would leave the driver decide unless the
> > user changes the options).
> 
> Just how many users would do that?

We can not tell how many users are using it since those users normally are not savvy Linux users. They do not sign in to Linux discussion mailing list/group for help. They complain to hardware/OS vendors.

The root cause of supporting current driver options is X server/input allows user to set options by means other than g-c-c. For example, users can set many options, not just TPCbutton option, through xorg.conf before X driver starts. Unless we remove all the means that lead to an option change before X server starts, we have to consider this case. If we do not deal with the predefined options, UI has no way to represent the true driver status.

> > That would be in g-s-d rather and no UI option (so this bug would move to g-s-d
> > instead - the patch is actually for g-s-d, sorry).
> 
> I would add support for org.gnome.settings-daemon.peripherals.input-devices
> hotplug-command to the wacom plugin, and let people call xinput by hand if they
> really wanted to change the tablet pc property (and remove the tablet pc
> property from the wacom schemas)

I think once end users get to UI, we should not refer them back to command line. Keeping the UI end user friendly is a goal, isn't it? 

It is not just in g-s-d. We need it in g-c-c too.

(In reply to comment #7)
> It is not just in g-s-d. We need it in g-c-c too.

Given that we still can't get a good explanation of what it does, I'd say no.

If the tablet-pc behaviour is enabled, the following is required to get a button 2 click:  press the stylus button _and_ press the stylus tip on the tablet surface. Button clicks while hovering are not possible.

(In reply to comment #8)
> (In reply to comment #7)
> > It is not just in g-s-d. We need it in g-c-c too.
> 
> Given that we still can't get a good explanation of what it does, I'd say no.

Use cases are posted at linuxwacom-discuss mailing list in reply to Peter's request. I know you are in that list. The use cases are also listed at https://bugzilla.redhat.com/show_bug.cgi?id=855294 in reply to Jakub's request. Please give me more details on which part of "what it does" is not explained good enough to you. I am willing to meet your standard.

Since Bastien needed more explanation, I went back to the discussion again. I think we may have misused some of the terms, or even worse, we are not on the same page in some areas between UI and X driver. My comments are inline.

(In reply to comment #3)
> When mode is "auto" (default), the setting is left completely untouched, ie
> whatever is set by the driver initially remains.

Although "auto" indicates a mode (on or off) from driver, it could have been set by end users (or their admins) in xorg.conf.d. So, it may be different from the driver's default/initial mode. 

In UI, we should display the current running mode from the driver when user opens g-c-c the first time. The mode displayed should either be "on" or "off". From my experience. this is necessary for those dummy[1] users who do not know what exact mode they are in.

With that said, my question is, is "auto" a mode in UI for end users to choose? If so, we'll need to explain why there are three options when mode is a binary.

I hope "auto" is not an option for end users. 

> Note, switching from "on" of "off" will _not_ reset to the driver default
> (since it's lost), "auto" works only before the option is changed either
> manually on by "g-s-d".

Do we support "default" function in UI? If we do, it should set options back to g-s-d's default values, which should be in sync with driver's defaults.

This and the above comments apply to all options, not just TPCButton.

[1] By dummy I mean that people who truly need an UI ;).

Please remember that Jakub from the GNOME Design Team considers adding an option in gnome-control-center for this a "UI failure":

     https://bugzilla.redhat.com/show_bug.cgi?id=855294#c7

     "[...] I would, however, see exposing this specific case for everybody in
      the system settings as a UI failure and go for a key only. [...]"

That's why the proposed patch is for g-s-d alone and adds a 3rd option to the existing key, since that seemed the more logical path.

Yet if a UI options is required, we need to convince GNOME design.

(In reply to comment #12)
> Please remember that Jakub from the GNOME Design Team considers adding an
> option in gnome-control-center for this a "UI failure":
> 
>      https://bugzilla.redhat.com/show_bug.cgi?id=855294#c7
> 
>      "[...] I would, however, see exposing this specific case for everybody in
>       the system settings as a UI failure and go for a key only. [...]"

note the "everybody" here. exposing this option to bamboo users, or Cintiq users, etc. may not be appropriate, exposing it to a TabletPC user may be.

(In reply to comment #4)
> Why is this an option at all if the driver knows better? (better than the user
> even?)

The driver does not know better. The problem is that user (or his system admin) may have set the option before driver even started. It is not a scenario that is unique to TPCbutton. It could happen to all other xorg.conf.d or external script enabled options. If your suggestion of not supportting it in UI is based on this scenario, there would be not many options we can/need to support.

I have mentioned the above before and I would not want to repeat it again. However, I think we have missed one foundamental point here: what is the purpose of a software UI? It is definitely not for developers like you and I. It is for end users. Without a true user friendly UI, Linux on desktop would only be a dream, a daydream.

(In reply to comment #14)
> I have mentioned the above before and I would not want to repeat it again.
> However, I think we have missed one foundamental point here: what is the
> purpose of a software UI? It is definitely not for developers like you and I.
> It is for end users. Without a true user friendly UI, Linux on desktop would
> only be a dream, a daydream.

The purpose of "software UI" isn't to present every possible option as a toggle or option box. That's how you make crap UIs. Options have a cost. See http://ometer.com/free-software-ui.html if you haven't read it yet.

(In reply to comment #13)
> (In reply to comment #12)
> > Please remember that Jakub from the GNOME Design Team considers adding an
> > option in gnome-control-center for this a "UI failure":
> > 
> >      https://bugzilla.redhat.com/show_bug.cgi?id=855294#c7
> > 
> >      "[...] I would, however, see exposing this specific case for everybody in
> >       the system settings as a UI failure and go for a key only. [...]"
> 
> note the "everybody" here. exposing this option to bamboo users, or Cintiq
> users, etc. may not be appropriate, exposing it to a TabletPC user may be.

That's more useful. Now, how do we label the option?

(In reply to comment #14)
> note the "everybody" here. exposing this option to bamboo users, or Cintiq
> users, etc. may not be appropriate, exposing it to a TabletPC user may be.

Exactly my (next) plan, once we get the integration patch merged into libwacom we shall have a way to identify the form factor, ie integrated tablets in screen and system so we can add a UI control only for those devices (which is a much smaller subset of devices).

And then we leave the settings in g-s-d as it is, I don't think removing existing settings would help.

(In reply to comment #15)
> Options have a cost. See http://ometer.com/free-software-ui.html if you 
> haven't read it yet.

No, I didn't read it before. You should give me the link earlier. It makes me think about how to explain what TPCbutton does in a way that fits the good UI requirement. It also makes me feel that we are on the same page to make a "clean, simple, consistent, productive" UI.

The purpose of TPCbutton is to offer a consistent user experience when users migrate from Windows to Linux. TPCbutton is the default setting for Windows Tablet Edition. That's why it is default in X driver for TPC. However, for those Windows users who disabled TPCbutton while they ran Windows, we want to welcome them to Linux world too. Offering them an UI access to the setting is a simple solution before they know how to use the powerful Linux command line and other advanced features without UI. We are not following Windows. We just want to make sure Windows users don't feel lost too much when they first come to our world. 

> > note the "everybody" here. exposing this option to bamboo users, or Cintiq
> > users, etc. may not be appropriate, exposing it to a TabletPC user may be.
> 
> That's more useful. Now, how do we label the option?

Other people used hover. I feel it is hard to explain what is "hover disabled" v.s "hover enabled". The word hover itself is quite confusing in this content. So, I introduced TPCbutton to reflect the fact that it's a button mode on Windows TPC. I am fine with any label of your choice. The bottom line is we make it easy to understand for our potential users.

Adds a dependency on bug 689599 to use the new libwacom 0.7 API to identify integrated system devices (tablet PC)

Created attachment 230746 [details] [review]
New patch adding a UI option for ISD only

This new proposed patch adds a new UI option "Hover click" taht's visible only on integrated system devices (thanks to the new libwacom API addition) .

Note, I choosed "Hover click" which works opposite of "Tablet PC" mode because I don't think "Tablet PC" is as explicit as "Hover click", but I woudl gladly change that to whatever is preferred if that can help with acceptation of this patch.

Similarly, the layout is ugly, admittedly, but I am not very good at this so I am completely open to any suggestion regarding the UI layout of course.

At last, if we really do *not* want a UI option for this, we could always set tablet-pc mode only for ISD since we can easily identify those now with libacom, but since this bug is about adding a UI option, here it comes.

Review of attachment 226442 [details] [review]:

::: data/org.gnome.settings-daemon.peripherals.wacom.gschema.xml.in.in
@@ +42,3 @@
       <_description>Enable this to move the cursor when the user touches the tablet.</_description>
     </key>
+    <key name="tablet-pc-button" enum="org.gnome.settings-daemon.GsdWacomTPCButtonMode">

You'll need to change the name, unless you have assurances that the DConf database supports have a particular key's type change from under its feet.

Review of attachment 230746 [details] [review]:

::: panels/wacom/cc-wacom-page.c
@@ +1012,3 @@
+
+	/* if Hover Click is enabled this is the equivalent of TPC behaviour disabled. */
+	g_settings_set_boolean (priv->wacom_settings, "tablet-pc-button", !gtk_switch_get_active (sw));

I thought it was an enum now...

The enum was if we were to add "auto", which apparently is not what we want so attachment 226442 [details] [review] is old stuff now, we don't change anything to the DConf database.

The new patch attachment 230746 [details] [review] is just about adding a new UI option.

attachment 230746 [details] [review] still isn't landable as the label for the feature is still too opaque for my taste.

Saying a meal is not your taste is too opaque for your chef to cook something to perfection for you. A constructive comment would give concrete examples about your preference. Postponing a fix to a later release does not resolve the issue unless we have solid plan to fix it. Please show your suggestions so we can move forward.

(In reply to comment #24)
> Saying a meal is not your taste is too opaque for your chef to cook something
> to perfection for you. A constructive comment would give concrete examples
> about your preference. Postponing a fix to a later release does not resolve the
> issue unless we have solid plan to fix it. Please show your suggestions so we
> can move forward.

I'll respond one last time, but your comments asking for me to come up with better wording are completely useless and only serve to grate me.

I'm the maintainer, and I'm responsible for the project. It's not up to me to come up with better wording. Designers with input from the developers should be doing that  (which is why the ui-review keyword is set on the bug). All I know is that the label isn't good.

Hi Bastien,

Sorry for having grated you. My intention was to get the job done sooner. Plus, I wanted to please you since I really wanted to understand how we can meet your taste. It must be my poor English skill betrayed me (it is easier to blame something else than to accept our own fault ;-). With that said, I am honest enough to be responsible for whatever bad feelings my comments have caused. It was my fault.

I know how a maintainer who is responsible for a project feels - he wants to get the job done in a right way. We are in the same boat, like it or not ;-).

Can you please respond one more time with a bit more detail on the directions how a good label would be? Or, maybe you want to bring UI experts like Jakub Steiner to the discussion? Trust me, I do not want to complicate this discussion. My only intention is to find a solution for the project.

Maintainer change

Looking into this.

Hey,

Got a few comments about this.

I believe we should provide this tablet PC option (and I prefer hover mode/click as a term, also because I had looked into Wacom's documentation and I think they talked about hover clicks).

I tried the patch by Olivier and the Cintiq tablet I have attached to my machine didn't show the tablet PC option so I tried playing with xsetwacom command. To my surprise (I'm still new to this), the tablet PC setting it uses is applied to the stylus devices and not the tablet itself.
Now I think it would be a design failure to have this option available for all the styli connected to a device so it's better to have it per tablet but, regarding what I'm saying above, we need to support more than tablet-pc/isd ones.

About the default settings. I think it's gonna be tricky to keep a consistency between whatever the driver's defaults are and gsd (as I can always change it outside of g-c-c). Ideally, we would set the default to be the current driver's value but what I think is more important to reflect whatever is shown on g-c-c so I'd prefer to override the driver's default and let the user choose if the our default doesn't fit their taste.

Comments?

(In reply to comment #29)
> Hey,
> 
> Got a few comments about this.
> 
> I believe we should provide this tablet PC option (and I prefer hover
> mode/click as a term, also because I had looked into Wacom's documentation and
> I think they talked about hover clicks).
> 
> I tried the patch by Olivier and the Cintiq tablet I have attached to my
> machine didn't show the tablet PC option so I tried playing with xsetwacom
> command. To my surprise (I'm still new to this), the tablet PC setting it uses
> is applied to the stylus devices and not the tablet itself.

X.org and the Wacom devices create multiple devices. It's assigned to the stylus because it doesn't make any sense to assign to the associated touch device, cursor (mouse), or the tablet itself.

> Now I think it would be a design failure to have this option available for all
> the styli connected to a device so it's better to have it per tablet but,
> regarding what I'm saying above, we need to support more than tablet-pc/isd
> ones.

Why do we need to support more than tablet PCs or ISD?

The only problem here is the label of the functionality, not the functionality itself.

(In reply to comment #30)
> (In reply to comment #29)
> > Hey,
> > 
> > Got a few comments about this.
> > 
> > I believe we should provide this tablet PC option (and I prefer hover
> > mode/click as a term, also because I had looked into Wacom's documentation and
> > I think they talked about hover clicks).
> > 
> > I tried the patch by Olivier and the Cintiq tablet I have attached to my
> > machine didn't show the tablet PC option so I tried playing with xsetwacom
> > command. To my surprise (I'm still new to this), the tablet PC setting it uses
> > is applied to the stylus devices and not the tablet itself.
> 
> X.org and the Wacom devices create multiple devices. It's assigned to the
> stylus because it doesn't make any sense to assign to the associated touch
> device, cursor (mouse), or the tablet itself.

Alright. It just surprised me, that's all :)

> 
> > Now I think it would be a design failure to have this option available for all
> > the styli connected to a device so it's better to have it per tablet but,
> > regarding what I'm saying above, we need to support more than tablet-pc/isd
> > ones.
> 
> Why do we need to support more than tablet PCs or ISD?
> 
> The only problem here is the label of the functionality, not the functionality
> itself.

Well, again, I new with the Wacom tablets so bear with me. I just assume that if my Intuos supports this hover click functionality, as a user, I might prefer to use it that way.

I understood this bug had to do with functionality, with the approach of dealing with the defaults settings and how to present them to the user. Maybe I misunderstood it, we're passed that point and all that is needed is to choose a nice label then.

(In reply to comment #29)
> I believe we should provide this tablet PC option (and I prefer hover
> mode/click as a term, also because I had looked into Wacom's documentation and
> I think they talked about hover clicks).

I think I used the term hover click when implementing properties in the driver. not sure how it came to be tbh but I think the term TabletPC is more common. Then again, neither really describes what the option actually does so I think some new term would be a good idea.

> I tried the patch by Olivier and the Cintiq tablet I have attached to my
> machine didn't show the tablet PC option so I tried playing with xsetwacom
> command. To my surprise (I'm still new to this), the tablet PC setting it uses
> is applied to the stylus devices and not the tablet itself.


As Bastien said, we create multiple devices off a single kernel device, largely for historical reasons and because the XInput protocol isn't overly useful otherwise. the default devices are usually stylus, eraser, cursor, pad and touch where applicable. But you can lock down to a specific physical ID at which point you'll see multiple stylus devices, each of which will only react to that ID.

The TPC option is global though, it'll apply to all styli. However, since it's largely used for tablet PCs which don't necessarily have an ID (and thus cannot have multiple styli) we probably don't need to worry about it.

> About the default settings. I think it's gonna be tricky to keep a consistency
> between whatever the driver's defaults are and gsd (as I can always change it
> outside of g-c-c). Ideally, we would set the default to be the current driver's
> value but what I think is more important to reflect whatever is shown on g-c-c
> so I'd prefer to override the driver's default and let the user choose if the
> our default doesn't fit their taste.

fwiw, having defaults that are different to the driver's isn't much of an issue IMO. they're just defaults. the only request I have though is that if you override an option please provide an interface to it.

Hi,

If the bug is only about the wording here are the solutions I propose:
1) Use "hover click" for the label (much better than tablet PC IMO because at least it gives a hint of what it does) and summarize what turning it on or off does in a tooltip. Something like:
"Enabling hover click allows for pressing a stylus's button while its tip is close to the screen to trigger its action; if it is disable, it is necessary to press a stylus's button and tap on the screen."

2) Use a label "Click mode" pointing to a button whose label is the current mode (Hover click OR tablet PC). When the user clicks the button, we see something similar to this:
https://lh4.googleusercontent.com/-rW_Yw2KEjgg/TW_2S64dByI/AAAAAAAAXgY/e0DMcMEEZBI/s400/Picture%25207.png

I think 2) might be a bit more alien to GNOME's way of doing things but we could get some input from a designer about these solutions.

I really dislike exposing this at all, and believe the long tail use case should be served with a dconf key.

That said, I do like the term "hover click" and I do prefer to explicitly explain the two modes in a separate modal behind the 'click mode' button if windows tablet pc users is somebody who we care about more than anyone else. I would appreciate if this button was only exposed to those with appropriate hardware (if we can't add likelihood of also running windows).

Hi Jakub,

This will be exposed only to appropriate hardware.

As for checking if people are running Windows, I really don't think that's a good idea. AFAIU, the relationship with the Windows users had to do with using the tablet-pc term, not the function itself because I may want to tweak it even if I come from OSX or no other OS at all.
Besides, I think it is just weird to use the existence of another OS to determine our features (unless we're talking about e.g. low-level/partitioning stuff).

I'll add the modal dialog as say (notice it'll be similar to how OSX approaches this problem).

I'd like to describe the problem area to mouse focus modes in X. There are endless debates on what's better, people have grown to use one or another, but the split/options create more problems than they solve. We should stick to one behavior and provide a way for people way too used to the other mode to override it with dconf/tweak tool. I would really prefer not to expose this for everyone.

We have missed the key point of the request for UI support. As Olivier stated in his bug description, 'the default value of "false" is always applied and there is no UI control to enable it'. The root cause is not we need to add the UI option in g-c-c, it is that g-s-d should not change driver existing settings to "default". That is, g-s-d should not touch the option if g-c-c does not offer an option for end users to change it back. This setting defaults have affected more options than TPCButton/"hover click".

I am fine with the suggestion to let end users/system admins use dconf/tweak/xorg.conf/xsetwacom. Should we go through the options that we do not plan to add to g-c-c? g-s-d should leave those options alone if there is no g-c-c interface for them.

Hi folks,

Finally I could finish the patch for the GNOME Tweak Tool for tweaking this option.

See https://bugzilla.gnome.org/show_bug.cgi?id=699298 .

Jakub told me the switch is okay for him. Removing ui-review.

The patch in GNOME Tweak Tool got pushed so I guess we can close this.