Re: How can i make kate behaviour go back to normal?

(note, I don't have a strong opinion about this change in particular and I
didn't
test the implementation yet since I switched back to distro provided
packages
for Kate a while back. I comment here mostly to provide a point of view
outside
of the KDE devs bubble).

> Can you explain why this is worse UX?

I am the co-maintainer of a popular tiling window manager called AwesomeWM.
Our users are not very fond of embedded dialogs rather than actual windows.
It's
inconvinient to suddently have a window that requires a larger size to
function
properly. For people who appreciate tiled workflows rather than a
fullscreen
window, the ods that Kate will be hard capped at whatever width 80 columns
(or 120, 160, whatever) of text it needs. Next to it, there will probably
be
some terminals or web browser windows. In AwesomeWM, you are (by default),
you
can easily toggle a single window to be temporarely fullscreen to handle
such
limitations, but it's annoying.

In the early Mac OS 9/X releases, they were still convinced spatial
navigation (aka,
a lot of windows rather than a back button) was the future. Because of that
they
made the windows very small and resize themselves (or have some drawers
sticking out) to accomodate needing more space. It was a mess and nobody
liked
this. That's also an issue with Kirigami unfortunately, but for them there
are
more technical reasons for this and Kirigami handle small size pretty well
with
custom "mobile" interfaces.

Windows 3.x and 95 were also really into MDI paradigms for no reasons.
People
also were not very happy with that and MDI pretty much died. Anchored docks
sidebars replaced this pretty well in the following decades. As long as you
can
hide them by default, they are a lesser evil. Not great for tiling users,
but
manageable because you can avoid them, unlike a hardcoded settings layer.

Tabbing is pretty much the modern way of doing "I want to have window
management
in my application". It's popular mostly because the classic window managers
are
not really well suited to manage a large number of windows. They are
optimized
for a few. Alt-tab isn't useful when you need to search among 1000 web
browser
tabs. In Kate, the QuickOpen filter is by far the fastest way to switch
file.
Those tabs/filters UXex also have the avdantage of providing some kind of
bundling at the window level. For Kate, that's projects. Other window
manager
level tricks (Activity, virtual desktop, tags) will never be as good as a
well
implemented tabs interface since the application has a lot more context than
the window manager.

Are the setting *pages* tabs in the new UI or it is just the KConfigDialog
as a
QWidget? If it works that way, at least it's semi consistent with other
apps the
users might encounte like VSCode, Firefox and Chrome. On the other hand,
tiled window manager users don't really like applications having their own
tabs either. They would rather do this at the window management level
rather
than app level because of the same "different minimum size" problem.
Anyhow,
tabs per page would also fix the "I want to see the effect of a change
witout
closing anything" problem mentionned earlier.

So IMHO, the dialog was fine, consistent and behave well for tiled window
managers. If it is deemed too old-school and Kate need to explore other
avenues,
then 1 tab per page among the existing tab bar and document tree would be
the
next best thing. Chrome/Firefox/VSCode paved the way.

Cheers,
Emmanuel
On Sun, 11 Dec 2022 at 02:58, Waqar Ahmed <[email protected]> wrote:

> Hi,
>
> Can you explain why this is worse UX?
>
> 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.
>
> Why should we block the editor when the dialog is open? Give me one
> reason.
>
> 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.
>
> 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.
>
> Regards
>
> On Sun, Dec 11, 2022, 3:45 PM Albert Astals Cid <[email protected]> wrote:
>
>> El dissabte, 10 de desembre de 2022, a les 15:46:26 (CET), Christoph
>> Cullmann
>> (cullmann.io) va escriure:
>> > On 2022-12-10 11:03, Albert Astals Cid wrote:
>> > > I don't want the settings dialog to not be a dialog.
>> > >
>> > > I don't want an unremovable "Open Widgets" in the file tree taking
>> > > space for
>> > > things that actually need to take space in the tree.
>> >
>> > Hi,
>> >
>> > there is no setting to turn this back,
>>
>> That's really unfortunate, all i can see it's just worse UX, I can't see
>> a
>> single reason on why having the settings dialog not be a dialog is an
>> improvement. (not even mentioning how it's buggy in some scenarios, see
>> https://i.imgur.com/uU1ACYB.mp4 )
>>
>> > but we shall avoid the empty entry,
>> > should only be there if there are any widgets.
>>
>> https://bugs.kde.org/show_bug.cgi?id=462896
>>
>> Cheers,
>>   Albert
>>
>> >
>> > Greetings
>> > Christoph
>> >
>> > > Cheers,
>> > >
>> > >   Albert
>>
>>
>>
>>
>>