Maybe Web UI technology will make Krita's UI development richer/prettier and more flexible ?

Greetings everyone.
First of all, I’m not familiar with UI/UX development with Qt.
But if you have some time to discuss, what do you think about web UI technology as a solution for
the development of desktop apps ? Is there any developer very familiar with this solution ? If there is, do you think Krita can benefit from this in the future ?

I’m saying all of this because well :
1.

I was reading this article too.

And because I don’t have experience on the actual tech side myself, but knows that web browsers exist, are cross platform, and utilize that kind of solution for the appeal of their User
Interface, I’m wondering if it’d be good to consider this for Krita in the future.

That frontend stuff really is something.

One of the main issues with anything running in the browser is that you are usually sandboxed to it, this means limited access to hardware and input devices.

When you want things fast than you usually have to work close to the hardware, that’s why Krita is written in C/C++.

Krita also relies a lot on Qt’s libraries, moving to a browser would not only mean reimplementing the whole user interface but also some qt features.

There is much more that would need to change than simply swapping the UI.

From my own experience (not with Krita but with other projects) you either work with web UI from the start or don’t do it at all. Depending on how you do it it’s even more work since you have to test your app in every browser and version or you have to ship your own browser instance like cefSharp (that’s how we do it where I work) but that’s another huge can of worms.

1 Like

So it’s not possible to use Html and Css for the front end of Krita while the backend is handled with Qt and C/C++ ?

You can use a HTML front end for a c++ application but currently we have qt and you need to swap qt for a browser wich can’t be done easily without rewriting huge parts of krita.

You have a house built with bricks, but suddenly one day there is this hip new concrete mixture. So you think hey let us just rebuild the house with this. Remove the bricks and just replace it with this new mixture. Easy right.

It is not impossible to do anything, but is it needed or is it just stupid time waste. We need to think about that. Instead of doing that you can just work with the current available tech and improve the UI.

4 Likes

And you have a foundation that doesn’t fit the concrete because it was set up for bricks so you have to rebuild parts of the foundation too.

I agree. And that’s why I was asking questions on the subject.

Which is a problem. Finally, is it possible to have a customized titlebar for Krita in the sense that crossplatform compatibility isn’t a problem for this feature ?

The Problem with the title bar (the part that usually contains the minimize, maximize or close button) is that this part of a window is usually not managed by the application but the OS’s window manager. MacOS for example has a global titel bar at the top of the screen that also contains the menu. Gnome and some Linux Desktops have this too. In windows every Window has it’s own titel bar and menu bar and other window managers maybe do it the same or some other way.

So because of that, anybody who wishes to customize the title bar has to target the OS window manager. While it’s not impossible, it would lead to more work and more code to write and maintain for each platform the app is compatible with. Which explains why it discourages developers, because it’s not a simple matter, and is definitely not urgent.

In conclusion, even if web ui technologies exist and could help to make the front end compatible on all platforms, Krita was already built with tons of bricks on its foundations.
So, this technology might simply be ignored as a solution for the redesign of Krita’s UI ?
Aaah… The life of a developer isn’t easy I guess…

Actually changing the title bar in any way from within an application is pretty much impossible since the operating system’s window manager and the theme (if the OS has theming) control this. It’s pretty much out of reach and for a reason. Operating systems do this to make sure all the windows behave and look the same.

The most you can usually do is set a title text and if the close, maximize, minimize buttons are visible/enabled. Or hide the title bar (borderless window mode)

Using a web UI wouldn’t change anything. It just would then show the title bar of the browser window.

On some Linux desktops you could customize the title bar appearance but that would change it for all applications.

Regarding the examples you posted, they use borderless window mode and then recreated an element that looks like a title bar with a menu.

Edit: On my KDE Plasma Desktop I could disable the title bar of any window if I like for some reason. Other operating desktops don’t make it that easy. But as I wrote, it’s not a feature of the application, but of the window manager.

1 Like

Let me guess.
Recreating such element in Krita as well is too much work because the the cross paltform compatibility constraint.

Do you confirm ?

Well, adding a close, minimize or maximize buttons to the menu bar is more or less easy but a title bar has a lot more functionalities. Like on my desktop it allows me to keep the windows above/under other windows, disable borders, shadows, keep it on all virtual desktops, lock it to workspaces, change transparency and much more. Now Krita would have to reimplement every possible window manager feature for every possible operating system for its self made title bar. Imagine how much work this is instead of simply using the systems title bar that already can do all this.

And it can have other side effects. I knew some applications that did this and it lead to having double title/menu bars on gnome 3 and mac os, one in the application and the global title bar at the top of the screen.

In addition especially Mac users have strong feelings when the title bar doesn’t has the OS theme wich would be the case too.

I have one last question.
Is it not possible, say to hide the default OS titlebar but keep some of its essential functionalities( resize, minimize, maximize, close, window order, tabbing ) and thus keep the customized look of the titlebar nonetheless, without having to reimplement all the OS window management features ?

(the side effects you pointed out, seems more like a bug to me…)

Is reimplementing all OS window management features the only way for this ?

If you use windows you can choose a color for the system theme and that matches Krita’s color scheme.

Although I do think it would be good if Krita had her own title bar, since at least it causes me a bug in the stylus of the tablet if I have the dockers undocked and switch between them and the main window.

You can of course just reimplement just a subset of common functions but I promise you it will take only a few days until people will complain about things not working as before and features missing. First will be me if “keep window above others” is missing.

And you can’t hide the system title bar (when we are talking about the global title bar some OS like mac have) because for some Desktop environments this is also the place where the clock or tray icons are shown. You can only hide the application’s title bar but that sometimes also means you can’t move the windows any more because the title bar is the handle for this most of the time.

But honestly this extra work is simply not worth it in almost all cases because the window manager does the job much better and, well, it’s the entire job of the window manager to do this so applications don’t have to. And when Qt doesn’t have methods to implement all these things a cross platform way you find yourself writing a lot of platform specific code to handle the window which the OS could do better and consistent.

Honestly, I’m not sure what your issues with the title bar is.

I doubt it would help, sadly :wink:

For everything else in this thread… there is Photopea, if someone wants a web application. We still need a good UI for tablets, so it will be rewritten anyway, plus there are all the Qt 6 issues. And we are just finishing rewriting resource management. I have enough of rewriting Krita, frankly.

2 Likes

True, I think the problem is with the Huion driver :neutral_face:, with my wacom one this doesn’t happen.

1 Like

The only and only issue is “to have more space” by merging app titlebar with the OS titlebar.
But it seems to be impossible without an already made perfectly working and open source product(a framework ?) which handles this in the sense that it gets rid of cross-platform compatibility issues.

Because I once looked a UI redesign mockup proposed by @Dmitry for Krita, a UI which I liked a lot for its aesthetics and ergonomics.

Here’s a screenshot :

If on all platforms Krita was like this and there were no titlebar, but the functionalities of common OS window management are still maintained, then, to me at least, it would be a plus.

Depending on your Operating system you will automatically have this. It should look like this on Mac OS and Gnome 3 desktops when maximized. If you really need these ten extra pixels you can simply disable the title bar. As mentioned on my Desktop with KDE Plasma I just right click on the title bar and select “No border”. Maybe your OS can do something similar or with a third party application. In my opinion fixing things that don’t need a fix is a waste of development time that could be invested in something more useful.

The title bar should also be gone in full screen mode.

1 Like