darktable-org / darktable

darktable is an open source photography workflow application and raw developer
https://www.darktable.org
GNU General Public License v3.0
9.79k stars 1.14k forks source link

Locating and applying the `en@truecase` option isn't intuitive. #17411

Open RokeJulianLockhart opened 2 months ago

RokeJulianLockhart commented 2 months ago

Is your feature request related to a problem? Please describe.

  1. As https://github.com/darktable-org/darktable/issues/2078#issuecomment-2322921369 states:

    Reading entirely lower-case labels is difficult for me. You can see in the responses to https://ux.stackexchange.com/q/33708/132515 that the data is inconclusive on this topic (although this revision of this answer provides a useful explanation of my opinion on this).

  2. As https://github.com/darktable-org/darktable/issues/2078#issuecomment-2315695311 states:

    I had to search within the closed issues section on this tracker to ascertain that the option would be listed as a translation, and even then, the fact that a restart of the application is necessary isn't communicated to the user - I expected that the feature didn't function after I hit apply (because there was no success feedback there either).

Summarily, the sentence case feature isn't easily discoverable - it's in the language flyout, despite not being a language - and applying it isn't intuitive:

  1. The "Save" button doesn't indicate success; and:
  2. The "Restart to apply" pill notification appears solely in the parent window, despite the child configuration window not closing automatically upon application (which would be undesirable, but would at least display the notification to the user).

Describe the solution you'd like

As https://github.com/darktable-org/darktable/issues/2078#issuecomment-2323013164 states:

What is your proposal?

My best idea is to have a checkbox appear when en-.* is selected, which is labelled "Sentence case".

I can't imagine that having a checkbox appear or disappear based upon the chosen translation would be problematic to implement, and it would prevent the translation flyout being used to non-translation language stylisation attributes.

Alternatives

Most assistance is provided in tooltips:

Screenshot_20240901_115200

However, as https://github.com/darktable-org/darktable/issues/2078#issuecomment-2323277612 states:

Tooltips aren't inherently discoverable (due to there being no indication of whether a tooltip exists for an element) and don't function on touchscreen displays.

These are reasons that that KDE is moving to using contextual help buttons, per https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/240 and https://discuss.kde.org/t/element-specific-help-should-be-displayed-consistently/15624/2?u=rokejulianlockhart as others are.

Summarily, provide a button that invokes the tooltip, rather than a hover action, so that the user:

  1. Knows that an assistance tooltip is available; and:
  2. Knows that they are able to invoke it irrespective of their preferred input method.

The undermentioned is a step in the correct direction:

image

Additional context

Posted here per https://github.com/darktable-org/darktable/issues/2078#issuecomment-2323027798:

The place for discussions is in open issues. If you have an idea to improve the UI please raise a new issue and discuss it there.

elstoc commented 2 months ago

the sentence case feature isn't easily discoverable

You could propose an insert into the user manual to flag this up.

Summarily, provide a button that invokes the tooltip, rather than a hover action

We should be consistent so this would be a change to the whole application if desired (I'm not sure it's a good idea, especially given we already have context-sensitive help that points to the user manual). This would therefore be better as a separate feature request.

I can't imagine that having a checkbox appear or disappear based upon the chosen translation would be problematic to implement

It's problematic if the translation gets dropped due to lapse in its maintenance, as it would lead to a non-functioning tick box. The whole idea of this change was to limit its impact by using pre-existing functionality. There's nothing stopping you from submitting a pull request to the repository proposing this change though.

My best idea is to have a checkbox appear when en-.* is selected

One day I might get annoyed with all the American spellings and propose an en-GB translation, but without a sentence-case variant. In this case the proposed solution will not work

RokeJulianLockhart commented 2 months ago

We should be consistent so this would be a change to the whole application if desired (I'm not sure it's a good idea). This would therefore be better as a separate feature request.

@elstoc, I agree - it's rather outside the scope of this. I'd be glad to file it if you think it's of worth, or merely to have the issue linked here, if ever it's created.

It's problematic if the translation gets dropped due to lapse in its maintenance, as it would lead to a non-functioning tick box. The whole idea of this change was to limit its impact by using pre-existing functionality.

Is that currently a concern?

There's nothing stopping you from submitting a pull request to the repository proposing this change though.

@elstoc, surely you're aware that for the vast majority of people there is - I'm unable to develop in C, Lua, or C++. I'm still getting the ropes of damn CSS.

One day I might get annoyed with all the American spellings and propose an en-GB translation, but without a sentence-case variant. In this case the proposed solution will not work

In which case, I could merely rescope this to en-US, surely?

elstoc commented 2 months ago

Is that currently a concern?

With FOSS, people come and go. So I don't know if/when this will become a concern.

Anyway, as you might have gathered, apart from perhaps an addition to the user manual, I'm not sure I agree that these suggestions are necessary.

RokeJulianLockhart commented 2 months ago

perhaps an addition to the user manual

@elstoc, I've created https://github.com/darktable-org/dtdocs/pull/677#issue-2499406360 per your suggestion.

With FOSS, people come and go. So I don't know if/when this will become a concern.

Indeed, but if there's no reason to believe that this shall occur, why not build upon it?

elstoc commented 2 months ago

@elstoc, I've created https://github.com/darktable-org/dtdocs/pull/677#issue-2499406360 per your suggestion.

Thanks

victoryforce commented 2 months ago

With FOSS, people come and go. So I don't know if/when this will become a concern.

Indeed, but if there's no reason to believe that this shall occur, why not build upon it?

@RokeJulianLockhart Why do you think that there is no reason to believe?

RokeJulianLockhart commented 2 months ago

https://github.com/darktable-org/darktable/issues/17411#issuecomment-2344434713

@victoryforce, because I've not been informed of a reason to. Surely that's inherent to such a statement? Apologies if I've misunderstood.

github-actions[bot] commented 2 days ago

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.