Hello.
When tabbar.multiline is enabled and there are more
then one row of file tabs (buffers), clicking on a tab on top row will
move the entire top row to the bottom. This makes it a nightmare to
track where is what. Is there a setting disable this behaviour?
Thank you.
This is annoying. I haven't used the tabbar in a while. Now I remember why. Also because it flickers. ( And because it sometimes triggers a CTRL+A on the editor, which feels like a race condition; althoguh this happens predictably if you right click on a tab bar, is this a feature? ). It is very unpleasant to use!
But I think there is a way.
The trick is to use LBS_BUTTONS (but only in multline mode). The tabs will look a little different (i feel they're nicer now), but the control is ugly anyhow. There's that TCS_FLATBUTTONS style to play with in case that makes it better.
Tests have yielded the following:
TCS_SINGLELINE | TCS_TABS : OK, works as expected.
TCS_SINGLELINE | TCS_BUTTONS : rearranges the tabs in strange ways.
TCS_MULTILINE | TCS_TABS : is the cause for the issue here and may wreak havoc on the unsuspecting mind.
TCS_MULTILINE | TCS_BUTTONS : OK, works as expected.
So we should use TCS_TABS with TCS_SINGLELINE and TCS_BUTTONS with TCS_MULTILINE. If the visual difference is an issue, we could still always give TCS_OWNERDRAWFIXED a try.
There's a tiny issue here (I'm still searching for the docs on this). The tab control seems to no longer send TCN_SELCHANGE notifications but sends NM_CLICK instead. The required changes though are minimal and work fine in my quick tests.
Also note that LBS_MULTILINE can be toggled during the control's lifetime, but LBS_BUTTONS can only be set during creation. But this shouldn't be a problem, i.e. to create a brand new control at property change (given how the tab bar is a flickering mess already). Morover, as it is now, changing the tabbar.multiline property seems to require an app restart to take effect (obviously I believe we can do better here).
Patch is coming up over at SF.
> Windows 7 - yes old stuff
I'm still stuck on winXP, so no judgement from me ;).
> I mitigated it ...
It's always good to try a workaround first, but I feel you were much too patient here!
> Whoever designed that control probably never UX-tested it seriously.
True.
> If the graphic result is not totally ugly ...
Actually, I think it's more beautiful. I might use it more often now myself. Just a grid of buttons. I've posted a screencap (see below) since this is going to take a little longer than expected (ditto).
> I guess that behavior is reasonable: as I get it from the docs, TCS_BUTTONS style makes the tab bar just a row of buttons ...
Thankfully the individual buttons do act as a group, hence like a tab bar, still. My expectation was that, if it's in _essence_ a tabbar control, then it should adhere to the same user-interface regardless of its _accidental_ styles. I suspect the design decision here was to keep it as light-weight as possible: they simply plugged in button controls and didn't subclass their behavior to conform to the tabbar contract.
> I would prefer to restart SciTE instead of having a little more convenience
True. Unless ... with 30+ files open, I'm not so sure (session save/restore helps, alas there's the file-loading overhead ... and what if I really want to quickly toggle all the tabs into view and out again?). To misquote JFK, ask not what you can do for SciTE etc.
In any case, I know that this is not a requirement of Windows, to have to restart an app in order to change chrome. Now I'm hoping that it's not a requirement of SciTE's cross-platform nature (see below).
> I'm always against adding more code bloat ...
I'm trying hard not to change too much here.
> Care to share a link?
It's not ready yet, but there is a screencap here <https://sourceforge.net/p/scintilla/feature-requests/1366/>.
The patch is here <https://sourceforge.net/p/scintilla/feature-requests/1366/#6bcd>. Nothing special.
Repopulating the tab bar can be optimized with this patch which keeps a copy of the tab text and only updates changed, added, or removed tabs.
The reason the tab control moves the active tab to the bottom is that its folder-tab-open-at-bottom tries to make the tab appear attached to the document. The button mode isn’t trying to maintain this appearance so doesn’t move.
I originally wrote a version that called TabCtrl_GetItem but ...
There appears to be no way to determine the size of a tab item’s text to allocate the amount needed.
The patch is using its own logic for determining the correspondence between buffers and tab text but does not appear to take into account read-only ‘|’ or dirty ‘*’ indicators. File names that include ‘&’ may also be an issue as they are modified by EscapeFilePathsForMenu.
The time cost of GUI redrawing is huge compared to computation cost. Unless the comparison appears significant in a profile, it likely isn’t worth pursuing.
Possibly we could derive our own allocator for the vector so that it triggers an update of each TC_ITEM's lParam whenever the memory layout changes?
It would have to check that the addresses hadn't changed ...
Not unless it can be shown to be a problem.
The current tab bar position is already known to Windows so whether the SetPosition is needed could be checked against that.
Its possible that Windows already optimizes a no-op SetPosition.
This code was originally more complex to deal with old versions of Windows and some of the complexity has remained.
A single source of truth is much less likely to go wrong. For me, modelling the tab bar contents as a simple vector of strings is a great simplification that should be robust against future needs and is likely to work cross-platform.
This was informed by SwiftUI and some of the more functional JavaScript UI frameworks.
I would love to see both making it into production.
in my program, caret still active when editor pane not active.There are multiple editor windows in my program.When the editor window is not active, for example you click in the console pane, the text caret is still visible and flashing in the editor - meant to indicate that it is ready to have text typed there, however it is not, keystrokes are ignored until you click in the editor.
1. Create a window
2. Create all Pane and and all child-window loaded in PANE, such as Tree, Hexeditor, etc., and hide some PANE
(At this point, some PANE loaded Scintilla, but this PANE does not have focus, and the main window has just created at this time)
3. Then the things previously described appeared
(When this happens, you need to use controls within the PANE with SCINTILLA to use the mouse point)
- Create a window
- Create a part you need to display the PANE, and create the child window loaded in these Panes.
- Other PANE and child windows, create when the first time you need to display
- BUG solves
--
You received this message because you are subscribed to the Google Groups "scite-interest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scite-interes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scite-interest/40F66457-1F4D-402D-873A-96D86C248C83%40me.com.