New tabs added on the right?
Dominik Haumann
dhaumann at kde.org
Mon May 13 07:29:18 BST 2019
It is the correct code location.
However, calling it a bug that the documents order changes when resizing is
not entirely correct. The tab bar is not a normal tab bar. Instead, it
displays only as many tabs as can fit, and if there are more open documents
that fit, the least recently used ones are hidden, and next to the tab bar
appears a button "+5" indicating there are 5 more documents that are not in
the tab bar.
Now to the important point: if you never change the order, we would not be
able to add a tab, since what tab should be removed if the tab bar is full?
Right now, we hide the least recently used tab, and add the new tab on the
left.
I think these are two distinct cases:
1. Add tab on the right, if there is still space.
2. Add tab on the left, if there is not enough space (i.e. another tab gets
hidden).
Thoughts?
For bugs: go to bugs.kde.org, use the advanced search, choose component
kate, and search for tabbar or tabs:
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=1619221&product=kate&query_format=advanced&short_desc=Tabs&short_desc_type=allwordssubstr
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=1619222&product=kate&query_format=advanced&short_desc=Tabbar&short_desc_type=allwordssubstr
The bug you are looking for is:
https://bugs.kde.org/show_bug.cgi?id=390043
Greetings
Dominik
Andy Doucette <andy.doucette at gmail.com> schrieb am Mo., 13. Mai 2019, 04:39:
> Can you point me to the bug report please? I might move this disucssion
> there.
>
> I'm sifting through the code a bit. 100,000 lines is quite a lot to sift
> through. Thank goodness it's well commented. ;)
>
> I think I've found a relevant section:
> kate/kateviewspace.cpp:256
> bool KateViewSpace::showView(KTextEditor::Document *document)
>
> I think part of the reason new tabs are added on the left is that when you
> resize the window to be really small, and then make it bigger again, your
> active tab ends up moving from whatever position it was in to the left-most
> position. I can see why you'd always want your current tab to be visible,
> but I think it's a bug for the tab order to change based on this history of
> your window resizing. So, once that bug is addressed and we get stable tab
> order regardless of resizing, I think we can just change line 281 here to
> add at the end of the list instead.
>
> 256 bool KateViewSpace::showView(KTextEditor::Document *document)
> 257 {
> 258 const int index = m_lruDocList.lastIndexOf(document);
> 259
> 260 if (index < 0) {
> 261 return false;
> 262 }
> 263
> 264 if (! m_docToView.contains(document)) {
> 265 return false;
> 266 }
> 267
> 268 KTextEditor::View *kv = m_docToView[document];
> 269
> 270 // move view to end of list
> 271 m_lruDocList.removeAt(index);
> 272 m_lruDocList.append(document);
> 273 stack->setCurrentWidget(kv);
> 274 kv->show();
> 275
> 276 // in case a tab does not exist, add one
> 277 if (! m_docToTabId.contains(document)) {
> 278 // if space is available, add button
> 279 if (m_tabBar->count() < m_tabBar->maxTabCount()) {
> 280 // just insert
> 281 insertTab(0, document);
> 282 } else {
> 283 // remove "oldest" button and replace with new one
> 284 Q_ASSERT(m_lruDocList.size() > m_tabBar->count());
> 285
> 286 // we need to subtract by 1 more, as we just added
> ourself to the end of the lru list!
> 287 KTextEditor::Document * docToHide =
> m_lruDocList[m_lruDocList.size() - m_tabBar->maxTabCount() - 1];
> 288 Q_ASSERT(m_docToTabId.contains(docToHide));
> 289 removeTab(docToHide, false);
> 290
> 291 // add new one always at the beginning
> 292 insertTab(0, document);
> 293 }
> 294 }
> 295
> 296 // follow current view
> 297 Q_ASSERT(m_docToTabId.contains(document));
> 298 m_tabBar->setCurrentTab(m_docToTabId.value(document, -1));
> 299
> 300 return true;
> 301 }
>
>
> Do you think this is the right call? Does this course of action make
> sense to you? I want to make sure I'm barking up the right tree before I
> start editing code.
>
> Cheers,
> Andy
>
>
> On Mon, May 13, 2019 at 6:27 AM Andy Doucette <andy.doucette at gmail.com>
> wrote:
>
>> Lovely! :) I'll dive in today. The easiest change would just be to
>> reverse it. It would take significantly more work to add a config option
>> to reverse it. Do you think just reversing it is acceptable?
>>
>> On Mon, May 13, 2019 at 1:02 AM Dominik Haumann <dhaumann at kde.org> wrote:
>>
>>> Hi Andy,
>>>
>>> yes, patches are accepted for sure.
>>> You may do a git blame to find out why a certain line of code was added.
>>> I remember I once changed this for some reason, but it seems it was not a
>>> smart change. I think we even have a bug report for it.
>>>
>>> Thanks
>>> Dominik
>>>
>>> Andy Doucette <andy.doucette at gmail.com> schrieb am So., 12. Mai 2019,
>>> 16:04:
>>>
>>>> Hello! I use kate as my main text editor for development and love it.
>>>> It does _almost_ everything I need. One thing that consistently bothers me
>>>> is that new tabs seem to get added on the left instead of the right. Every
>>>> other system I use adds new tabs on the right. Since most of us in the
>>>> west read from left to right, it makes sense to me that if I open a parent
>>>> class and then open a child class and then open a grandchild class, they
>>>> should be from left to right in my editor.
>>>>
>>>> This bothers me to the point that I might even be willing to try and
>>>> learn a new codebase to make the change. My main question is: If I
>>>> submitted a pull request that swapped the order, would the "powers that be"
>>>> accept it? I could probably figure out how to add a config option to make
>>>> it optional even. Just would be nice to have the choice.
>>>>
>>>> Sincerely,
>>>> Andy
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20190513/b3dd1eba/attachment-0001.html>
More information about the KWrite-Devel
mailing list