<div dir="ltr"><div dir="ltr">(note, I don't have a strong opinion about this change in particular and I didn't<br>test the implementation yet since I switched back to distro provided packages<br>for Kate a while back. I comment here mostly to provide a point of view outside<br>of the KDE devs bubble).<br><br>> Can you explain why this is worse UX?<br><br>I am the co-maintainer of a popular tiling window manager called AwesomeWM. <br>Our users are not very fond of embedded dialogs rather than actual windows. It's<br>inconvinient to suddently have a window that requires a larger size to function<br>properly. For people who appreciate tiled workflows rather than a fullscreen <br>window, the ods that Kate will be hard capped at whatever width 80 columns <br>(or 120, 160, whatever) of text it needs. Next to it, there will probably be <br>some terminals or web browser windows. In AwesomeWM, you are (by default), you<br>can easily toggle a single window to be temporarely fullscreen to handle such<br>limitations, but it's annoying.<br><br>In the early Mac OS 9/X releases, they were still convinced spatial navigation (aka, <br>a lot of windows rather than a back button) was the future. Because of that they<br>made the windows very small and resize themselves (or have some drawers <br>sticking out) to accomodate needing more space. It was a mess and nobody liked <br>this. That's also an issue with Kirigami unfortunately, but for them there are <br>more technical reasons for this and Kirigami handle small size pretty well with <br>custom "mobile" interfaces.<br><br>Windows 3.x and 95 were also really into MDI paradigms for no reasons. People<br>also were not very happy with that and MDI pretty much died. Anchored docks<br>sidebars replaced this pretty well in the following decades. As long as you can<br>hide them by default, they are a lesser evil. Not great for tiling users, but<br>manageable because you can avoid them, unlike a hardcoded settings layer.<br><br>Tabbing is pretty much the modern way of doing "I want to have window management<br>in my application". It's popular mostly because the classic window managers are<br>not really well suited to manage a large number of windows. They are optimized<br>for a few. Alt-tab isn't useful when you need to search among 1000 web browser<br>tabs. In Kate, the QuickOpen filter is by far the fastest way to switch file.<br>Those tabs/filters UXex also have the avdantage of providing some kind of<br>bundling at the window level. For Kate, that's projects. Other window manager<br>level tricks (Activity, virtual desktop, tags) will never be as good as a well<br>implemented tabs interface since the application has a lot more context than<br>the window manager.<br><br>Are the setting *pages* tabs in the new UI or it is just the KConfigDialog as a<br>QWidget? If it works that way, at least it's semi consistent with other apps the<br>users might encounte like VSCode, Firefox and Chrome. On the other hand, <br>tiled window manager users don't really like applications having their own <br>tabs either. They would rather do this at the window management level rather <br>than app level because of the same "different minimum size" problem. Anyhow, <br>tabs per page would also fix the "I want to see the effect of a change witout<br>closing anything" problem mentionned earlier.<br><br>So IMHO, the dialog was fine, consistent and behave well for tiled window<br>managers. If it is deemed too old-school and Kate need to explore other avenues,<br>then 1 tab per page among the existing tab bar and document tree would be the<br>next best thing. Chrome/Firefox/VSCode paved the way.</div><div><br></div><div>Cheers,</div><div>Emmanuel<br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 11 Dec 2022 at 02:58, Waqar Ahmed <<a href="mailto:waqar.17a@gmail.com">waqar.17a@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Hi, </div><div dir="auto"><br></div><div dir="auto">Can you explain why this is worse UX? </div><div dir="auto"><br></div><div dir="auto">This is an improvement, as it allows you to change settings without reopening the dialog every time. It also makes tweaking the theme and editor settings a lot more pleasant which was just a crappy experience in the past. </div><div dir="auto"><br></div><div dir="auto">Why should we block the editor when the dialog is open? Give me one reason. </div><div dir="auto"><br></div><div dir="auto">Of course there will be bugs, but we can always fix them (hopefully). After watching the video I was not able to tell what was the issue. Maybe I need to watch more closely.</div><div dir="auto"><br></div><div dir="auto">Regarding the Open Widgets being an item, it was sort of unfinished in the way that it doesn't hide when there are no widgets to close. I didn't have time to test it so I went for the basic version where it disabled the tree item instead of hiding. </div><div dir="auto"><br></div><div dir="auto">Regards<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sun, Dec 11, 2022, 3:45 PM Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">El dissabte, 10 de desembre de 2022, a les 15:46:26 (CET), Christoph Cullmann <br>
(<a href="http://cullmann.io" rel="noreferrer noreferrer" target="_blank">cullmann.io</a>) va escriure:<br>
> On 2022-12-10 11:03, Albert Astals Cid wrote:<br>
> > I don't want the settings dialog to not be a dialog.<br>
> > <br>
> > I don't want an unremovable "Open Widgets" in the file tree taking<br>
> > space for<br>
> > things that actually need to take space in the tree.<br>
> <br>
> Hi,<br>
> <br>
> there is no setting to turn this back,<br>
<br>
That's really unfortunate, all i can see it's just worse UX, I can't see a <br>
single reason on why having the settings dialog not be a dialog is an <br>
improvement. (not even mentioning how it's buggy in some scenarios, see<br>
<a href="https://i.imgur.com/uU1ACYB.mp4" rel="noreferrer noreferrer" target="_blank">https://i.imgur.com/uU1ACYB.mp4</a> )<br>
<br>
> but we shall avoid the empty entry,<br>
> should only be there if there are any widgets.<br>
<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=462896" rel="noreferrer noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=462896</a><br>
<br>
Cheers,<br>
  Albert<br>
<br>
> <br>
> Greetings<br>
> Christoph<br>
> <br>
> > Cheers,<br>
> > <br>
> >   Albert<br>
<br>
<br>
<br>
<br>
</blockquote></div></div></div>
</blockquote></div></div>