Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Thu, Aug 04, 2016 at 04:53:13PM +0200, Helge Hafting wrote:
 
> Middle-clicking on a tab does not provide a location, only which document to
> paste into. So I would expect the current selection to be pasted into the
> current cursor position of the document in that tab.

Interesting, I didn't think about this possible expectation.

> > 1b. What do you think *should* happen?
> Pasting into another document than the active one may be useful, but
> dangerous if the user don't see what happens. So perhaps LyX should switch
> to that document so the user don't get surprised later. Or perhaps this
> should only work for the active tab?

We decided to set it so that middle-click closes a tab. In my opinion
the strongest argument for why this makes sense is because Chromium and
Firefox do it. I don't think that should be the only argument, but since
we don't have UI specialists here, I think it's good to try to be as
consistent as possible with other tab-related applications.

> > 
> > 2a. What do you *expect* to happen if you middle-click on the space to the
> > right of the tabs? I'm referring to the blank space where if you had
> > more tabs it would take that space up.
> Nothing - pasting anything there makes no sense. If I want a context menu,
> I'll right-click.
> > 2b. What do you think *should* happen?
> Nothing. Unless you can come up with something useful? To be intuitive, it'd
> have to be paste-related?

Middle-click is not just used for paste. See above.

> Note that making every part of the screen sensitive to clicks & drags is
> unpleasant. It is nice to have some places where a click/drag is not
> "dangerous" - so one can click to raise/focus the window (or check if it has
> focus already). But this applies more to the left button.

Good point. I agree. Not just for raise/focus behavior but also for
errant clicks. For a similar reason I think that saturating the keyboard
shortcuts (i.e. assigning a shortcut to every key combination) is not a
good idea.

Thanks for the feedback, Helge.

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[Helge Hafting]

Den 20. juli 2016 08:33, skrev Scott Kostyshak:

Dear LyX users,

I'm implementing a very small feature and before I proceed further I
would like to get a little feedback. I have two questions that are
relevant if you have more than one document open in LyX, using tabs.

1a. What do you *expect* to happen if you middle-click on a tab?
Middle-click is "paste", it pastes the current selection into whatever 
the mouse cursor is over. A very useful feature of X11, one can quickly 
mark & paste stuff without having to use "ctrl+c" or menu choices like 
"copy" and "paste". A nice and extremely quick way of getting text from 
one place to another. Works inside LyX, and works between LyX and other 
programs (web browsers, terminals, ...)


Middle-clicking inside the main window pastes at the location 
clicked.Middle-clicking anywhere text can be entered, will paste text there.


Middle-clicking on a tab does not provide a location, only which 
document to paste into. So I would expect the current selection to be 
pasted into the current cursor position of the document in that tab.



1b. What do you think *should* happen?
Pasting into another document than the active one may be useful, but 
dangerous if the user don't see what happens. So perhaps LyX should 
switch to that document so the user don't get surprised later. Or 
perhaps this should only work for the active tab?


2a. What do you *expect* to happen if you middle-click on the space to the
right of the tabs? I'm referring to the blank space where if you had
more tabs it would take that space up.
Nothing - pasting anything there makes no sense. If I want a context 
menu, I'll right-click.

2b. What do you think *should* happen?
Nothing. Unless you can come up with something useful? To be intuitive, 
it'd have to be paste-related?


Note that making every part of the screen sensitive to clicks & drags is 
unpleasant. It is nice to have some places where a click/drag is not 
"dangerous" - so one can click to raise/focus the window (or check if it 
has focus already). But this applies more to the left button.


Helge Hafting

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Fri, Jul 22, 2016 at 07:52:59PM +0200, racoon wrote:

> How about a "full screen" option that is still windowed, i.e. a windowed
> mode that gets rid of selected elements, like toolbars and tabs?
> 
> - To begin with it could use the same settings of hidden elements as full
> screen.
> 
> - Keyboard shortcut: Some modifier+F11?
> 
> I am just brainstorming...

I'm sure there are improvements to be made. If you have something you
think makes sense make a ticket so we don't forget about it.

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[racoon]

On 22.07.2016 11:17, Scott Kostyshak wrote:

On Fri, Jul 22, 2016 at 10:41:08AM +0200, racoon wrote:

On 21.07.2016 02:04, Scott Kostyshak wrote:

On Wed, Jul 20, 2016 at 07:32:01PM -0400, Scott Kostyshak wrote:


Interesting idea. I guess we do not show it to use the extra space, but
I'm not sure which is best.


I doubt we are going to change this by default [...]


(Sorry for being slightly off-topic.)

I am not sure I understand why though.

If the reason is that the extra space is important to have then something
should be done about the spaces in LyX in general. Because I guess often
people work with several tabs anyway and if space is a problem there, then
it is a more general problem.


Yes it would be nice to improve vertical space in other ways.


How about a "full screen" option that is still windowed, i.e. a windowed 
mode that gets rid of selected elements, like toolbars and tabs?


- To begin with it could use the same settings of hidden elements as 
full screen.


- Keyboard shortcut: Some modifier+F11?

I am just brainstorming...

Daniel

Re: feedback on middle-clicking tab behavior

[PhilipPirrip]

On 07/21/2016 04:20 PM, Scott Kostyshak wrote:

or
www.lyx.org/trac/ticket/10289


Thanks Scott, it was 10289.
I added a comment to the discussion there.

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Fri, Jul 22, 2016 at 10:41:08AM +0200, racoon wrote:
> On 21.07.2016 02:04, Scott Kostyshak wrote:
> > On Wed, Jul 20, 2016 at 07:32:01PM -0400, Scott Kostyshak wrote:
> > > 
> > > Interesting idea. I guess we do not show it to use the extra space, but
> > > I'm not sure which is best.
> > 
> > I doubt we are going to change this by default [...]
> 
> (Sorry for being slightly off-topic.)
> 
> I am not sure I understand why though.
> 
> If the reason is that the extra space is important to have then something
> should be done about the spaces in LyX in general. Because I guess often
> people work with several tabs anyway and if space is a problem there, then
> it is a more general problem.

Yes it would be nice to improve vertical space in other ways.

> Always showing tabs seems also like pretty much the standard in other
> applications (e.g. browsers).

Good point. I wonder if it makes a difference that LyX has some toolbars
that take up a lot of space up top, and Chromium and Firefox do not.

> My guess is, as I suggested, that this is
> because there are certain functionalities when tabs are shown that users get
> used to which are lost when they are hidden.

I'm not sure what the reason is, but what you put makes sense.

> 
> I guess tabs could be shown by default but there could be a switch in
> 
> Tools > Preferences... > Look & Feel > Document Handling.

Could be.

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[racoon]

On 21.07.2016 02:04, Scott Kostyshak wrote:

On Wed, Jul 20, 2016 at 07:32:01PM -0400, Scott Kostyshak wrote:


Interesting idea. I guess we do not show it to use the extra space, but
I'm not sure which is best.


I doubt we are going to change this by default [...]


(Sorry for being slightly off-topic.)

I am not sure I understand why though.

If the reason is that the extra space is important to have then 
something should be done about the spaces in LyX in general. Because I 
guess often people work with several tabs anyway and if space is a 
problem there, then it is a more general problem.


Always showing tabs seems also like pretty much the standard in other 
applications (e.g. browsers). My guess is, as I suggested, that this is 
because there are certain functionalities when tabs are shown that users 
get used to which are lost when they are hidden.


I guess tabs could be shown by default but there could be a switch in

Tools > Preferences... > Look & Feel > Document Handling.

Daniel

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Thu, Jul 21, 2016 at 03:22:59PM -0400, PhilipPirrip wrote:
> 
> > 1a. What do you *expect* to happen if you middle-click on a tab?
> Nothing
> 
> 
> > 1b. What do you think *should* happen?
> 
> Switch to Master document.

Interesting idea.

> PLUS
> Left-click on a tab should switch to previously opened tab (switch between
> two documents)

There is a trac ticket that you might be interested that suggests
something similar (if I understand correctly). We are not currently
thinking about implementing it but perhaps you could join the
conversation. Trac is not working well now so I can't find the ticket. I
will take a guess though, and guess that it is either
www.lyx.org/trac/ticket/10287
or
www.lyx.org/trac/ticket/10289

Let me know if you can't find it once trac is back.

> > 2a. What do you *expect* to happen if you middle-click on the space to the
> > right of the tabs? I'm referring to the blank space where if you had
> > more tabs it would take that space up.
> Nothing.
> 
> 
> 
> > 2b. What do you think *should* happen?
> Nothing.

Nothing is the planned behavior for this one.

Thanks for the feedback,

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Thu, Jul 21, 2016 at 03:26:22PM -0400, PhilipPirrip wrote:
> On 07/20/2016 07:50 PM, Scott Kostyshak wrote:
> > 1. close the tab on middle-click
> 
> Would you still keep all the [×] buttons?

Yes. In my opinion middle-click should never replace any other behavior.
It should just add some bonus convenience. In this case, the convenience
is not having to precisely put the mouse over the tiny 'x'. But yes, we
will definitely keep the tiny 'x'.

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[PhilipPirrip]

On 07/20/2016 07:50 PM, Scott Kostyshak wrote:

1. close the tab on middle-click


Would you still keep all the [×] buttons?

Re: feedback on middle-clicking tab behavior

[PhilipPirrip]

1a. What do you *expect* to happen if you middle-click on a tab?

Nothing



1b. What do you think *should* happen?


Switch to Master document.
PLUS
Left-click on a tab should switch to previously opened tab (switch 
between two documents)




2a. What do you *expect* to happen if you middle-click on the space to the
right of the tabs? I'm referring to the blank space where if you had
more tabs it would take that space up.

Nothing.




2b. What do you think *should* happen?

Nothing.

Re: feedback on middle-clicking tab behavior

[Jean-Marc Lasgouttes]

Le 21/07/2016 à 02:04, Scott Kostyshak a écrit :

On Wed, Jul 20, 2016 at 07:32:01PM -0400, Scott Kostyshak wrote:


Interesting idea. I guess we do not show it to use the extra space, but
I'm not sure which is best.


I doubt we are going to change this by default, but if you want it for
your local build, just change the following:

// Hide tabbar if there's only one tab.
showBar(count() > 1);


If the tabbar was handled as a toolbar, it could have on/off/auto 
properties. I am not sure that such a thing is possible, though.


JMarc

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Wed, Jul 20, 2016 at 07:32:01PM -0400, Scott Kostyshak wrote:
> 
> Interesting idea. I guess we do not show it to use the extra space, but
> I'm not sure which is best.

I doubt we are going to change this by default, but if you want it for
your local build, just change the following:

// Hide tabbar if there's only one tab.
showBar(count() > 1);

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Thu, Jul 21, 2016 at 09:44:52AM +1200, gordon cooper wrote:
> 1a & 1b  also 2a & 2b.  I wold not expect anything to happen.
> 
> With my present mouse, which has a fairly light touch, I would
> prefer things to stay as they are - nothing.  The scroll and middle
> button are combined and as I tend to scroll often, another function
> (as happens in another application where middle button activates
> paste)  could be annoying. or else I develop a lighter touch.

You might want to disable middle-click on your mouse if it leads to
annoying behavior in more than one program (note that middle-button for
pasting the most recent selection is pretty common). That said, I'm sure
there are others who have the same opinion. Nonetheless, because there
is precedent (i.e. other programs implement similar behavior, see
below), I think we will implement some behavior.

After thinking about the feedback, I think that the most reasonable
approach is to:

1. close the tab on middle-click
2. do nothing when middle-clicking the blank space

The main reason for (1) is simply because Chromium and Firefox do it.
And although I can understand why some might be hesitant because of an
errant middle-click, my guess is that it does not happen too often, and
when it does happen there is no bad consecuence (Paul will be surprised
that the universe does not implode): if you have unsaved data, you will
be prompted just as you would be if you clicked on the "x".  And if you
don't have unsaved data, it might be confusing how one of the tabs
disappeared but you will be able to reopen it without any data loss.

Note that (1) was requested here:
http://www.lyx.org/trac/ticket/10288

(2) was more up in the air because Firefox opens a new tab, and Chromium
does nothing. Further, as Shay pointed out, we don't have a "new
document" button like in Firefox and Chromium. However, you can
double-click in the blank area to open a tab; and further judgingi from
the responses it seems like "nothing" is a reasonable choice.

Thank you all for the feedback! I will try to poll lyx-users more often.
I always get good feedback here. The only thing is that I usually work
on minor features so it is not a very exciting thing to give feedback
on. But as long as I get a few bites, I'll keep fishing.

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Wed, Jul 20, 2016 at 02:41:52PM +0100, Shay Riggs wrote:
> 1a. I’d expect the tab to close on middle-click (like Chrome).
> 1b. I think the tab should close.
> 
> 2a. I wouldn’t expect anything to happen.
> 2b. I don’t think anything should happen – but it would be great if there
> were a “new tab/document” button (like Chrome). I’d expect that to create a
> blank document using whatever the default settings are. (Can this be
> specified somewhere?)

I know it's not what you want, but you can currentl double-click on the
blank space and that creates a new tab.

Thanks for the info.

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Wed, Jul 20, 2016 at 07:33:05PM +, Paul A. Rubin wrote:
> Scott Kostyshak  lyx.org> writes:
> 
> I assume when you say "on a tab" you mean on the tab header.
> > 
> > 1a. What do you *expect* to happen if you middle-click on a tab?
> 
> The universe to implode (the Big Un-Bang?).

Well I guess we beat your expectations. You set a high bar.

> > 1b. What do you think *should* happen?
> 
> Nothing. If I middle-clicked on a tab, it was an accident.
> 
> > 2a. What do you *expect* to happen if you middle-click on the space to the
> > right of the tabs? I'm referring to the blank space where if you had
> > more tabs it would take that space up.
> > 2b. What do you think *should* happen?
> 
> Same as 1a and 1b.
> 
> Given that I have never had the impulse to middle-click either place, and
> that it's hard to do accidentally on my laptop and not terribly easily on my
> desktop, as far as I'm concerned you have carte blanche to assign anything
> lawful to either.

This is useful and probably a common opinion.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[Scott Kostyshak]

On Wed, Jul 20, 2016 at 09:48:39AM +0200, racoon wrote:
> On 20.07.2016 08:33, Scott Kostyshak wrote:
> > Dear LyX users,
> > 
> > I'm implementing a very small feature and before I proceed further I
> > would like to get a little feedback. I have two questions that are
> > relevant if you have more than one document open in LyX, using tabs.
> > 
> > 1a. What do you *expect* to happen if you middle-click on a tab?
> > 1b. What do you think *should* happen?
> > 
> > 2a. What do you *expect* to happen if you middle-click on the space to the
> > right of the tabs? I'm referring to the blank space where if you had
> > more tabs it would take that space up.
> > 2b. What do you think *should* happen?
> > 
> > Note that "nothing" is a perfectly acceptable answer. The "expect"
> > question is more about whether you're familiar with how things happen in
> > other applications that use tabs; the "should" question is more about
> > your opinion on what you would like to happen.
> > 
> > Scott
> 
> I was not expecting anything to happen since most of the time I used a
> portable computer that has no middle mouse button.
> 
> This is no answer you were seeking, but I think if anything should happen,
> it is a good idea to always show the tabs even if only one document is open.
> Otherwise the functionality works only in some context (where tabs are
> shown) but not others (where they aren't) and one would probably get used to
> a way to do things that always works (keyboard, menu, or software buttons).

Interesting idea. I guess we do not show it to use the extra space, but
I'm not sure which is best.

Scott


signature.asc
Description: PGP signature

Re: feedback on middle-clicking tab behavior

[gordon cooper]

1a & 1b  also 2a & 2b.  I wold not expect anything to happen.

With my present mouse, which has a fairly light touch, I would
prefer things to stay as they are - nothing.  The scroll and middle
button are combined and as I tend to scroll often, another function
(as happens in another application where middle button activates
paste)  could be annoying. or else I develop a lighter touch.

Gordon.

Re: feedback on middle-clicking tab behavior

[Paul A . Rubin]

Scott Kostyshak  lyx.org> writes:

I assume when you say "on a tab" you mean on the tab header.
> 
> 1a. What do you *expect* to happen if you middle-click on a tab?

The universe to implode (the Big Un-Bang?).

> 1b. What do you think *should* happen?

Nothing. If I middle-clicked on a tab, it was an accident.

> 2a. What do you *expect* to happen if you middle-click on the space to the
> right of the tabs? I'm referring to the blank space where if you had
> more tabs it would take that space up.
> 2b. What do you think *should* happen?

Same as 1a and 1b.

Given that I have never had the impulse to middle-click either place, and
that it's hard to do accidentally on my laptop and not terribly easily on my
desktop, as far as I'm concerned you have carte blanche to assign anything
lawful to either.

Paul

Re: feedback on middle-clicking tab behavior

[Shay Riggs]

1a. I’d expect the tab to close on middle-click (like Chrome).
1b. I think the tab should close.

2a. I wouldn’t expect anything to happen.
2b. I don’t think anything should happen – but it would be great if there
were a “new tab/document” button (like Chrome). I’d expect that to create a
blank document using whatever the default settings are. (Can this be
specified somewhere?)

-- Shay

On 20 July 2016 at 07:33, Scott Kostyshak  wrote:

> Dear LyX users,
>
> I'm implementing a very small feature and before I proceed further I
> would like to get a little feedback. I have two questions that are
> relevant if you have more than one document open in LyX, using tabs.
>
> 1a. What do you *expect* to happen if you middle-click on a tab?
> 1b. What do you think *should* happen?
>
> 2a. What do you *expect* to happen if you middle-click on the space to the
> right of the tabs? I'm referring to the blank space where if you had
> more tabs it would take that space up.
> 2b. What do you think *should* happen?
>
> Note that "nothing" is a perfectly acceptable answer. The "expect"
> question is more about whether you're familiar with how things happen in
> other applications that use tabs; the "should" question is more about
> your opinion on what you would like to happen.
>
> Scott
>

Re: feedback on middle-clicking tab behavior

[Jean-Marc Lasgouttes]

Le 20/07/2016 à 15:41, Shay Riggs a écrit :

I’d expect that to create a blank document using whatever the default
settings are. (Can this be specified somewhere?)


Yes, by using the "Save as Document Defaults" button of Document>Settings.

JMarc

Re: feedback on middle-clicking tab behavior

[racoon]

On 20.07.2016 08:33, Scott Kostyshak wrote:

Dear LyX users,

I'm implementing a very small feature and before I proceed further I
would like to get a little feedback. I have two questions that are
relevant if you have more than one document open in LyX, using tabs.

1a. What do you *expect* to happen if you middle-click on a tab?
1b. What do you think *should* happen?

2a. What do you *expect* to happen if you middle-click on the space to the
right of the tabs? I'm referring to the blank space where if you had
more tabs it would take that space up.
2b. What do you think *should* happen?

Note that "nothing" is a perfectly acceptable answer. The "expect"
question is more about whether you're familiar with how things happen in
other applications that use tabs; the "should" question is more about
your opinion on what you would like to happen.

Scott


I was not expecting anything to happen since most of the time I used a 
portable computer that has no middle mouse button.


This is no answer you were seeking, but I think if anything should 
happen, it is a good idea to always show the tabs even if only one 
document is open. Otherwise the functionality works only in some context 
(where tabs are shown) but not others (where they aren't) and one would 
probably get used to a way to do things that always works (keyboard, 
menu, or software buttons).


Daniel