Allow tab width to be set via "Edit -> Preferences -> Advanced". #59
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 4 commits
August 9, 2018 16:46
…s appropriately. (It should have been '4' before this branch was created, but Gtk didn't seem to care.)
…rable-tabs to include glade n_rows update.
davesp
changed the title
|
Making tabs reorderable as you provided has a problem which is now discussed on #50 . |
davesp
changed the title
|
The "autogen.sh" command results in "No package 'gtk+-2.0' found", and there's no such package in Debian "bullseye/sid". |
|
@davesp: The Debian package is called |
|
Thank you, that resolved the issue. It's been a while since I tried compiling this branch. Also had to add package "libvte-dev". |
|
Just merged the latest "lxde:master" into "davesp:add-tab-width-pref", and it still builds. Any thoughts on when this feature could be merged to master? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this modification is to allow users, who may open many tabs per window, to see the activity of their tabs without having to hit the left- and right-arrows on the tab line to find out if any of their tabs have had activity.
The new tab width takes effect when the next tab is created. If a tab width has not yet been set, the width is set to 100 (the default width in previous releases).
It might make for a cleaner UI if, when the new tab width is set, the current child tab label widgets were iterated-through to change their widths to the new setting; I'm open to suggestions as to how to best make that happen.
The proposed max (1000) may be a little high, but I was thinking about the width of screens these days. (Not sure who would want a tab 1000 pixels wide, though.)
Another option could have the width of each tab auto-resize to fit the contents of its current label, but doing so might defeat the goal of seeing the status of all tabs at once. (A possible enhancement could be a way to bring up a list of all of the tab titles to see their statuses, like "<Ctrl-A> <Enter>" in GNU Screen. Another day, perhaps.)
Any and all comments are welcome.