gdh1995
When grouped tabs get in the way of other tabs
One more issue: when several tabs are grouped and contracted, and I'm currently at the either side of the group, then after nextTab or previousTab I would jump into the tab in group, but my real intention is to the other side of the group(s):
Blue: My Intention
Red: Real action
Seems to need a command option to skip collapsed groups.
Um, then what behavior will you expect for commands like moveTabLeft ?
previousTab and nextTab's default action to ignore the collapsed groups (blue arrow); New commands or parameters to consider groups (red arrow); New commands to have some operations on groups, like collapseGroup, renameGroup, or shiftGroups etc.
previousTab and nextTab's default action to ignore the collapsed groups (blue arrow); New commands or parameters to consider groups (red arrow);
Got
like collapseGroup, renameGroup, or shiftGroups etc.
Currently those browser-level API are not exposed to extensions like Vimium C which has V2 manifest. Chrome has just supported V3 manifest this year, but it requires too many changes for Vimium C to work in the new mode. I'm somehow busy in my work, so Vimium C in V3 manifest will be delayed, um, maybe in 2022.
ignore the collapsed groups
Sad - the "collapsed" status requires Chrome's "tabGroups" permission and new V3 format. I can not work around it.
The original browser shortcuts Ctrl+Tab and Ctrl+Shift+Tab's action match my idea (ignore collapsed groups).
But there's no way to call "Ctrl+Tab"...
You mean mapkey? By the way, I've never succeed in making mapkey work, any issue?
I mean Vimium C can not "tell Chrome to run Ctrl+Tab", while it can only call chrome.tabs.update(tabId, { active: true }) to select another tab...
What're your mapkey lines?
Then Shift+F should work if you has map <f11> createTab (or another command)
The following special keys are available for mapping:
<c-*>,<a-*>,<m-*>for ctrl, alt, and meta (command on Mac) respectively with any key. Replace*with the key of choice.<left>,<right>,<up>,<down>for the arrow keys.<f1>through<f12>for the function keys.<space>for the space key.<tab>,<enter>,<delete>,<backspace>,<insert>,<home>and<end>for the corresponding non-printable keys (version 1.62 onwards).
https://github.com/philc/vimium/blob/bdf654aebe6f570f427c5f7bc9592cad86e642b5/README.md
<f1>through<f12>for the function keys.
I thought that it would behave as if I pressed f11 and then into fullscreen; that's the original browser shortcut.
Then Shift+F should work if you has
map <f11> createTab(or another command)
What is it good for to have an duplication of existing command without any modification?
as if I pressed f11 and then into fullscreen
No, mapKey can not affect how your browser handles the first key. It just let Vimium C treat a first key as the second key.
It's original usage is to solve keyboard layout issues (like this: https://github.com/gdh1995/vimium-c/wiki/Use-in-another-keyboard-layout#an-example-for-cyrillic-layout-russian-and-ukrainian). And I've added some new syntax so now it can make a same key work differently when Vimium C is in different modes (https://github.com/gdh1995/vimium-c/wiki/Use-in-another-keyboard-layout#mapkey-directive).
as if I pressed f11 and then into fullscreen
Maybe it's a good idea to have some cutomization commands doing so (as if I pressed some keys).
- There's neither API to trigger "tab-level" fullscreen, nor API to get the window status (size) before entering fullscreen.
- There's no API to let browser work "just as it does when receiving some special keys".
If you need such behavior, then AutoHotKey may help. On macOS and Linux there're also some similar system-level tools.
Fine.
previousTab and nextTab's default action to ignore the collapsed groups (blue arrow); New commands or parameters to consider groups (red arrow); New commands to have some operations on groups, like collapseGroup, renameGroup, or shiftGroups etc.
Sad - the "collapsed" status requires Chrome's "tabGroups" permission and new V3 format. I can not work around it.
So it looks like there's currently no way to implement any operation involving tab group, right?
Tab::groupId can be read, so moveTab has just been updated to keep a tab in its group. Others are impossible.
Reopened because this issue will be fixed, and is a necessary task in Manifest V3.
@gdh1995 Is it possible to call external processes for commands? If so, we can use a GUI automator to send the hotkey to Chrome, though this will probably be slow and buggy.
Another idea is to add a helper extension for Vimium that uses V3, to do stuff that needs those new APIs. I don't know how viable this is, and it isn't as elegant, but if it should work, it'll be much less work for you, I think? The helper extension can be merged back into the main extension when it starts using V3.
Web extensions like Vimium C can not call other system processes, but Vimium C does provide a command to send messages to other extensions, so a helper extension should work.
Thanks for your suggestion, and I'll look at it in about May.
Now that the relevant API support access, here are several features I've envisaged:
- filter commands on Vomnibar to show information about groups, including:
- group names followed by "- N," where N represents the number of tabs in this group,
- a monochromatic icon indicating the group color,
- constituent tabs' name replacing URLs of single tabs in the order of increasing name length,
- position of a group, with the count stack being distinguished from that of tab's (for example, count tabs' position as if no group is here, and so do groups as if they were tabs), in the form of the mild grey position indicator suffix,
- following icon indicating whether a group is collapsed (like the unmuted/muted icon).
- jumping to the first tab of the selected group in Vomnibar after
Enter, - commands to enter a new mode to select the target group to be collapsed/recolored/expanded/renamed/disintegrated/closed or moved to a new window,
- command to shift the position of a group, with Command Repetition setting the step, which is default 1,
- when shifting the tab at a group's boundary toward leaving the group it should keep the relative position with its tab neighbors (currently it can't even leave the group).
1-4. I don't want put much time to add commands of manipulating groups. I think Vimium C should just care about how to deal with existing groups correctly, and changes (except collapsing and expanding) can be done by user mouses and other professional extensions of managing workspace. 5. Now it's by design that a tab won't leave its group:
- for example, I map
>tomoveTabRight, and when I holding on > a current tab will move to the most right place. - we may discuss whether it's necessary or not (for Vimium C) to provide commands of adding / removing a tab to / from a near group.
[r] means you have pressed PageDownso many times that there's no more tabs of low scores - such a tab with[r]` has quite a high score and is re-added into the suggestion list, to fill the list and show a mark that "no more tabs matched".
~ is for "discarded" or "hidden" tabs. "Discarded" means resources of a tab have been "unloaded" to save memory and CPU, while Chrome keeps a place for the tab in the tab list, so that when you switch to it you'll see it will load from network again. "hidden" is a tab status in Firefox, which means a tab is not showing in the top list - this is used by some web-extensions to build their tab groups functionality (it occurs much earlier than Chrome's tabGroups).
Let alone the tab group, there're only two states a Chrome tab may possess: the normal state or being pinned, and they are far beyond enough. Tab group is an indispensable function for organizing a plethora of tabs, which frequently present in the tab bars of those who have procrastination (like me), so I think it should get the proper treatment it deserves.
can be done by user mouses and other professional extensions of managing workspace
Our tenet is to get everything done (as far as we can) without the mouse, isn't it? In terms of the diversity of command, completeness, and the user experience, Vimium-C is the super promotion of the original Vimium; it merits to keep going along this road to integrate more attractive functions into Vimium-C. You may feel free to ground the function needs at any time.
we may discuss whether it's necessary or not (for Vimium C) to provide commands of adding/removing a tab to/from a near group.
For flexibility, I recommend providing customization parameters to pass the option to users.
um, here're why i think so:
- 'tab groups' is like a temporary version of bookmarks
- there're quite a few famous extensions before this feature, like OneTab on Chrome and Firefox's (official?) Multi-account Container
- these extension have allowed users to control groups/containers by keyboard.
- Some ones did want Vimium to manage bookmarks and history, but they had very few approval comments.
- it seems that no similar issue reports in philc/vimium which want Vimium to control containers on Firefox.
As for moving a tab across groups, 'moveTab' now supports 'group=ignore'
---Original--- From: @.> Date: Fri, Apr 30, 2021 22:31 PM To: @.>; Cc: "Dahan @.@.>; Subject: Re: [gdh1995/vimium-c] When grouped tabs get in the way of other tabs (#317)
Let alone the tab group, there're only two states a Chrome tab may possess: the normal state or pinned. Tab group is an indispensable function for organizing a plethora of tabs, which frequently present in the tab bars of those who have procrastination (like me), so I think it should get the proper treatment it deserves.
can be done by user mouses and other professional extensions of managing workspace
Our tenet is to get everything done (as far as we can) without the mouse, isn't it? In terms of the diversity of command, completeness, and the user experience, Vimium-C is the super promotion of the original Vimium; it merits to keep going along this road to integrate more attractive functions into Vimium-C. You may feel free to ground the function needs at any time.
we may discuss whether it's necessary or not (for Vimium C) to provide commands of adding/removing a tab to/from a near group.
For flexibility, I recommend providing customization parameters to pass the option to users.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
this is necessary, of course.
---Original--- From: @.> Date: Sat, May 1, 2021 00:58 AM To: @.>; Cc: "Dahan @.@.>; Subject: Re: [gdh1995/vimium-c] When grouped tabs get in the way of other tabs (#317)
What about the first one? Merge group infomations into Vomnibar.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.