On Fri, Sep 21, 2018 at 2:47 PM, Bastien Nocera
wrote:
Those are not keyboard shortcuts, they're mnemonics, used for
navigating menus using the keyboard, not launching keyboard shortcuts
without opening the menu.
Feel free to start a new discussion about those, but they're really
not
the
On Fri, 2018-09-21 at 21:08 +0200, Tomasz Torcz wrote:
>
> Going extra mile to “find” shortcut is never gonna fly. Years ago,
> we
> had a perfect solution for discovering shortcuts – relevant letters
> were underlined in the menus. In some cases underlining appeared
> only
> after Alt was
On 09/21/2018 12:08 PM, Tomasz Torcz wrote:
> Going extra mile to “find” shortcut is never gonna fly. Years ago, we
> had a perfect solution for discovering shortcuts – relevant letters
> were underlined in the menus. In some cases underlining appeared only
> after Alt was pressed, which was
On Fri, 2018-09-21 at 11:59 -0700, Christian Hergert wrote:
> On 09/21/2018 11:43 AM, Shaun McCance wrote:
> > Can you elaborate on this? One of the goals of Mallard is to allow
> > plugin docs to integrate into the main app docs. Is there something
> > we
> > could be doing better?
>
> Advertise
On Fri, Sep 21, 2018 at 11:59:54AM -0700, Christian Hergert wrote:
> On 09/21/2018 11:43 AM, Shaun McCance wrote:
> > Can you elaborate on this? One of the goals of Mallard is to allow
> > plugin docs to integrate into the main app docs. Is there something we
> > could be doing better?
>
>
On 09/21/2018 11:43 AM, Shaun McCance wrote:
> Can you elaborate on this? One of the goals of Mallard is to allow
> plugin docs to integrate into the main app docs. Is there something we
> could be doing better?
Advertise the feature? :)
Does it work when they are installed into different
On Fri, 2018-09-21 at 10:36 -0700, Christian Hergert wrote:
> On 09/21/2018 04:24 AM, Allan Day wrote:
> > This would reduce
> > the number of menu items, allows cross-linking, and so on.
>
> This doesn't work well for situations where plugins are in play
> because
> those don't integrate cleanly
With regard to dropping the 'quit' action, is there any guidance for
background applications? That is, apps where closing all windows does
*not* exit the application, but the explicit 'quit' action does.
Cheers,
Florian
___
desktop-devel-list mailing
On Fri, Sep 21, 2018 at 4:00 PM Bastien Nocera wrote:
>
> On Fri, 2018-09-21 at 12:24 +0100, Allan Day wrote:
> > To be clear, I'm still thinking this through but, if you had a page
> > in
> > the user docs which was a simple table of keyboard shortcuts, which
> > was one click away in the user
On 09/21/2018 04:24 AM, Allan Day wrote:
> This would reduce
> the number of menu items, allows cross-linking, and so on.
This doesn't work well for situations where plugins are in play because
those don't integrate cleanly into the documentation. However, the
keyboard shortcuts window can handle
On Fri, 2018-09-21 at 12:24 +0100, Allan Day wrote:
> Bastien Nocera wrote:
> ...
> > > Putting aside the issue of outdated user docs,
> >
> > Well, it's a pretty big factor here.
>
> Can't we just remove out of date user docs?
We certainly can, though that means there's no place to put the
On Fri, 2018-09-21 at 14:26 +0100, Allan Day wrote:
> On Fri, 21 Sep 2018 at 12:54, wrote:
> >
> > On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera
> > wrote:
> > > It's faster to access for users, has terser explanations (no need
> > > to
> > > create sentences to describe actions) and it's
On Fri, 21 Sep 2018 at 12:54, wrote:
>
> On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera
> wrote:
> > It's faster to access for users, has terser explanations (no need to
> > create sentences to describe actions) and it's usually better updated
> > as it lives in the code, as opposed to being
On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera
wrote:
It's faster to access for users, has terser explanations (no need to
create sentences to describe actions) and it's usually better updated
as it lives in the code, as opposed to being separate in the docs.
It's also larger, well-designed,
Christian Hergert wrote:
...
> > "There is no need for the Quit menu item and the recommendation is to
> remove it from all locations."
>
> - What about applications that have multiple windows? It seems
> cumbersome to track down all your windows to ensure the application exits.
My answer right
On Fri, Sep 21, 2018 at 1:25 PM Allan Day wrote:
> Bastien Nocera wrote:
> > It's faster to access for users, has terser explanations (no need to
> > create sentences to describe actions) and
>
> To be clear, I'm still thinking this through but, if you had a page in
> the user docs which was a
Bastien Nocera wrote:
...
> > Putting aside the issue of outdated user docs,
>
> Well, it's a pretty big factor here.
Can't we just remove out of date user docs?
I realise that my line of reasoning is somewhat hypothetical here, but
if there are issues with the user docs, we ought to fix them.
My main hesitation to having the app level menu items (preferences,
keyboard shortcuts, help, about) always available is that it could
make the menus unpredictable - there is a clarity in having a definite
place for those items. Also, given that many of them are infrequently
used, requiring the
On Fri, 2018-09-21 at 11:05 +0100, Allan Day wrote:
> Bastien Nocera wrote:
> ...
> > ... The keyboard shortcuts dialogue in Videos is invaluable.
> >
> > Its contents used to be in the README file, which users wouldn't
> > see,
> > the user documentation still shows the old interface (from 4
Nathan Graule wrote:
...
> I feel like having the primary menu hidden in an in-window navigation app
> would be a regression from current, as a primary menu may apply anywhere, and
> having the user modify (and especially here, undo) application state in order
> to access a particular menu
Bastien Nocera wrote:
...
> ... The keyboard shortcuts dialogue in Videos is invaluable.
>
> Its contents used to be in the README file, which users wouldn't see,
> the user documentation still shows the old interface (from 4 years
> ago), and I'd rather not rely on user docs if I can help it.
21 matches
Mail list logo