On Wed, Apr 8, 2015 at 2:02 PM, Liviu Andronic <landronim...@gmail.com> wrote: > On Wed, Apr 8, 2015 at 7:51 PM, Scott Kostyshak <skost...@lyx.org> wrote: >> On Wed, Apr 8, 2015 at 1:48 PM, Liviu Andronic <landronim...@gmail.com> >> wrote: >>> On Wed, Apr 8, 2015 at 7:40 PM, Liviu Andronic <landronim...@gmail.com> >>> wrote: >>>> On Wed, Apr 8, 2015 at 7:08 PM, Scott Kostyshak <skost...@lyx.org> wrote: >>>>> On Wed, Apr 08, 2015 at 09:37:26AM +0200, Kornel Benko wrote: >>>>>> Am Mittwoch, 8. April 2015 um 01:29:11, schrieb Scott Kostyshak >>>>>> <skost...@lyx.org> >>>>>> > On Sun, Apr 5, 2015 at 8:40 PM, Richard Heck <rgh...@lyx.org> wrote: >>>>>> > > On 04/05/2015 07:47 PM, Scott Kostyshak wrote: >>>>>> > >> >>>>>> > >> It is currently bound to buffer-begin-select. But this LFUN is also >>>>>> > >> bound to C-S-Home. I would like to implement buffer-move-next, which >>>>>> > >> will move the tab up one spot (and similar for C-S-PageDown. This >>>>>> > >> feature and keybinding would be consistent with tab behavior in >>>>>> > >> Chromium, Firefox, and Nautilus. >>>>>> > > >>>>>> > > >>>>>> > > Seems reasonable. >>>>>> > >>>>>> > Attached is a patch. Note that in the patch there is cycling also when >>>>>> > moving. For example, if you are on the first tab, you can move it to >>>>>> > the last tab. I like this behavior and think it is consistent with tab >>>>>> > switching. However, it is not consistent with what chromium, >>>>>> > gnome-terminal, nautilus, and firefox do. They all disable such >>>>>> > cycling when moving. >>>>>> > >>>>>> > Thoughts? >>>>>> >>>>>> At least the emacs binding '\bind "S-C-KP_Prior" "buffer-move-next"' >>>>>> looks suspicious. >>>>> >>>>> Ah yes good eye. I will change that. >>>>> >>>>>> I like the switching. >>>>> >>>>> Does anyone have comments on the cycling when moving? For example if we >>>>> are on the first tab and move it to the left, currently it is moved to >>>>> the last tab. I will keep this behavior if no one comments. >>>>> >>>> If I understand correctly, this is a question of whether to wrap or not to >>>> wrap. >>>> >>>> In my opinion it is generally a good idea to NOT wrap tabs (windows, >>>> etc.) in such instances. It simply becomes very confusing for users >>>> when there are no clearly defined boundaries: beginning and last. For >>>> a discussion on this topic see: >>>> https://bugzilla.xfce.org/show_bug.cgi?id=6401#c6 >>>> >>> Moreover, currently when cycling tabs using the mousewheel LyX doesn't wrap. >>> >>> This makes sense, and should probably be kept for tab moving. >>> >>> Liviu >>> >>> >>>> Liviu >>>> >>>> >>>>> Scott >> >> >> Thanks, Liviu. This is useful. I see why not wrap for the mouse scroll >> wheel. But I don't see where it talks about something analogous to >> moving a tab. In LyX we do wrap when switching tabs, so why not wrap >> when moving tabs? >> > Actually, yeah, that's a good point. There is a big UI difference > between switching using mouse wheel vs keyboard (also discussed in the > above link). And as you say, we do wrap when switching tabs (and upon > thinking a bit more, it makes sense this way too). > > So I guess no complaints here...
OK, thanks for thinking about this and for the link, Liviu. I committed the patch at 6cf81782 and if someone prefers I can disable cycling when moving later. This would actually be a natural two commit approach anyway because I would probably do some generalizing of the code to get the current tab index. Currently the approach being used by GuiView::gotoNextOrPreviousBuffer is to cycle through all the tabs and check if the buffer is the same as the current buffer and that's how we find the current tab index. I would either stick that in a function that could be reused for getStatus or I would see if there is a more direct way to get the current tab index. Scott
