1 00:00:00,017 --> 00:00:04,097 Yeah, like after six, when it was the last session. Okay. 2 00:00:08,337 --> 00:00:11,997 So, I hope you all had a nice coffee break. Thank you for being here. 3 00:00:12,857 --> 00:00:17,917 I'm not supposed to be a session chair right now, so I should have come up with a joke by now. 4 00:00:18,737 --> 00:00:22,337 And then Eike stole my joke about the State of the Union, and Arjen doesn't 5 00:00:22,337 --> 00:00:25,697 want me to introduce it as the State of the Union, so I'll just leave the rest 6 00:00:25,697 --> 00:00:28,977 of the introduction to Arjen. That's fine. 7 00:00:30,437 --> 00:00:38,317 Hello, my name is Arjen Hiemstra. I am here to talk about a project that I've called Union, 8 00:00:39,157 --> 00:00:49,597 which I hope will become the future of everything styling within KDE and maybe even more than KDE. 9 00:00:54,777 --> 00:00:58,557 So, what I will start with, though, is some pictures. 10 00:01:05,937 --> 00:01:10,237 So, most of you will probably have seen some of these things. 11 00:01:11,017 --> 00:01:14,877 I'll start with this is Kate, probably familiar. 12 00:01:15,497 --> 00:01:19,937 This is Plasma, also quite familiar to most of you. 13 00:01:21,197 --> 00:01:27,577 We have Neo Chat, might be less familiar to people, but will still be familiar to a lot of you here. 14 00:01:27,577 --> 00:01:34,197 And then we have an application called KClock, which isn't all that familiar 15 00:01:34,197 --> 00:01:38,297 to most people, but still also a KDE application. 16 00:01:39,097 --> 00:01:45,337 So that's all great. We have four applications that look quite similar. 17 00:01:46,457 --> 00:01:51,517 So what's the problem here? Well, we have four applications, 18 00:01:51,697 --> 00:01:57,357 and we have four different implementations of the Breeze style. 19 00:01:57,957 --> 00:02:04,457 We have Kate using Qt Widgets, using Breeze. 20 00:02:05,157 --> 00:02:15,197 We have Plasma using Plasma style, using SVGs to supply that information. 21 00:02:15,197 --> 00:02:23,557 And then we have Qt Quick, which, in the case of Neo Chat, is its own special thing. 22 00:02:25,057 --> 00:02:35,057 And then in the case of KClock, it actually uses a Qt Quick-based implementation of the Breeze style. 23 00:02:37,777 --> 00:02:43,297 I hope that all of you recognize that having four different implementations 24 00:02:43,297 --> 00:02:47,497 of the same thing is already a problem, but sorry. 25 00:02:51,010 --> 00:02:59,230 Yeah, I intentionally didn't mention that one here, mostly because that's a 26 00:02:59,230 --> 00:03:00,570 whole different can of worms. 27 00:03:02,390 --> 00:03:04,330 But yes, you're right, there is a 28 00:03:04,330 --> 00:03:09,270 potential fifth in that we also have an implementation of Breeze for GTK. 29 00:03:12,890 --> 00:03:18,610 So, apart from that issue of having four different implementations, 30 00:03:18,810 --> 00:03:23,130 there are also issues with the individual implementations. 31 00:03:23,690 --> 00:03:32,090 Starting off with Qt Widgets implementation, which is build using the C++ Qstyle API, 32 00:03:32,410 --> 00:03:39,210 which Which is, to put it politely, not the greatest API, 33 00:03:39,750 --> 00:03:41,850 for doing stuff with this. 34 00:03:43,710 --> 00:03:47,310 I actually put up some code from the Breeze style. 35 00:03:47,970 --> 00:03:53,090 Basically, you need to manually paint all the individual controls. 36 00:03:54,210 --> 00:03:59,270 And it's very painful to make any changes to how Breeze looks in Q style. 37 00:03:59,270 --> 00:04:05,710 It takes a lot of time and effort and deep knowledge of how Qstyle works. 38 00:04:06,110 --> 00:04:10,790 So this is really not that great. 39 00:04:11,250 --> 00:04:22,850 And similarly, an additional problem here is that it is limited by specifically 40 00:04:22,850 --> 00:04:27,130 those types of widgets that Qstyle supports. 41 00:04:27,130 --> 00:04:32,410 So if you have a custom widget, which we don't all that much, 42 00:04:32,530 --> 00:04:40,050 but if you do have it, it also becomes quite hard to reuse the styling from Qstyle. 43 00:04:42,593 --> 00:04:49,033 On the other hand, we have the Qt Quick side, which is better. 44 00:04:50,633 --> 00:04:56,273 Qt Quick is styled using Qt Quick Control, or Qt Quick Control specifically 45 00:04:56,273 --> 00:05:02,473 is styled using QML files, which is already a lot easier to work with than Qstyle, 46 00:05:02,793 --> 00:05:04,993 but it still has its issues. 47 00:05:04,993 --> 00:05:11,433 Specifically one being if you make a mistake in your Qt Quick style, 48 00:05:11,833 --> 00:05:13,433 you can break applications. 49 00:05:14,733 --> 00:05:21,173 Which is dangerous when you want to include a custom style in like say, 50 00:05:21,333 --> 00:05:27,173 or inject a custom style in something like a Flatpak, which is a use case we do have. 51 00:05:30,733 --> 00:05:38,193 So to get around this issue of having multiple implementations of the style, 52 00:05:38,393 --> 00:05:42,513 at some point we developed Qt Quick desktop style, 53 00:05:42,753 --> 00:05:47,373 which makes use of the widget style, Q style, 54 00:05:47,773 --> 00:05:50,893 to render controls for Qt Quick. 55 00:05:52,593 --> 00:05:55,413 Which works. It means we have a bunch 56 00:05:55,413 --> 00:06:04,033 of things that don't require re-implementation but it also comes with its drawbacks 57 00:06:04,033 --> 00:06:13,353 because we're now limiting our Qt QuickSight by what the QStyle side supports which isn't great, 58 00:06:14,993 --> 00:06:21,273 so it's and there it also comes with a nice another drawback because QStyle 59 00:06:21,273 --> 00:06:23,153 is software rendered standard, 60 00:06:23,233 --> 00:06:30,733 which means that on mobile platforms, 61 00:06:31,073 --> 00:06:35,313 you now have an issue where the performance of this isn't great. 62 00:06:35,793 --> 00:06:44,353 So at some point, Noah actually, Noah Davis, built a version of the the Breeze 63 00:06:44,353 --> 00:06:46,373 style using pure Qt Quick, 64 00:06:46,613 --> 00:06:55,913 because that was targeted to help make KDE applications work better on Plasma Mobile, 65 00:06:56,253 --> 00:07:02,093 and that it did, but it didn't mean we had yet another implementation of Breeze. 66 00:07:05,918 --> 00:07:13,418 And then finally, we get back to Plasma, which has its own SVG-based system for styling, 67 00:07:13,678 --> 00:07:22,938 which is actually pretty decent to work with for non-developers. 68 00:07:22,938 --> 00:07:29,158 But even with them, when talking to them about it, it turned out, 69 00:07:29,198 --> 00:07:32,758 yeah, it's better to work with than, say, 70 00:07:32,898 --> 00:07:43,838 Qt Quick, but it's still an issue because SVG is not a format designed for making UIs in. 71 00:07:44,358 --> 00:07:47,778 It's a graphics format meant for making images. 72 00:07:47,878 --> 00:07:51,558 It's still not great for doing UIs. 73 00:07:51,558 --> 00:07:58,518 It additionally also runs into the issue that you now need to render these SVGs 74 00:07:58,518 --> 00:08:02,878 which comes with their own problems and performance penalties and everything. 75 00:08:04,798 --> 00:08:13,378 And additionally, the plasma styling still contain, 76 00:08:13,658 --> 00:08:19,858 misses the, the actual SVG file still miss a lot of information that is encoded 77 00:08:19,858 --> 00:08:27,658 in the Qt Quick that's making use of this about to identify which elements to 78 00:08:27,658 --> 00:08:29,838 use and all those kinds of details. 79 00:08:34,598 --> 00:08:39,718 So, I think you can all agree that we have a problem here. 80 00:08:40,638 --> 00:08:45,658 We actually, within the Visual Design Group and some other areas, 81 00:08:45,958 --> 00:08:48,738 we've identified this problem a while back. 82 00:08:49,538 --> 00:08:56,158 And it's taken a while to get to a solution. 83 00:08:56,458 --> 00:09:04,478 But basically, the question becomes, we have this problem. How do we move forward? 84 00:09:04,678 --> 00:09:07,338 How do we get to the next stage? 85 00:09:10,138 --> 00:09:16,718 So, yeah, we need something new because what we want to go to is the classic 86 00:09:16,718 --> 00:09:22,758 case of, hey, we now don't have 15 standards or five in our case. 87 00:09:22,958 --> 00:09:30,998 We now have just the one and just that one thing that we can use to build our UIs with. 88 00:09:34,473 --> 00:09:40,633 So just to work on, hey, what are we going to do with this? 89 00:09:40,793 --> 00:09:48,733 I came up with some requirements during a long, long process of getting to where we are now. 90 00:09:50,553 --> 00:09:56,893 So the main point being, we need something where we have a single source of 91 00:09:56,893 --> 00:09:59,373 truth for all our styling. 92 00:09:59,373 --> 00:10:02,173 Styling this is not this is 93 00:10:02,173 --> 00:10:05,613 something that also our designers want because they 94 00:10:05,613 --> 00:10:09,153 want to make changes to how things look but right 95 00:10:09,153 --> 00:10:12,693 now they are being blocked because we 96 00:10:12,693 --> 00:10:16,793 as developers say hey sorry we 97 00:10:16,793 --> 00:10:19,813 we like your ideas but we just can't do 98 00:10:19,813 --> 00:10:25,433 this because it's going to take way too much effort and way too much work to 99 00:10:25,433 --> 00:10:31,933 make these changes and in some cases it's even saying yeah well we can't technically 100 00:10:31,933 --> 00:10:36,813 do this here because we're being limited by for example cue style. 101 00:10:43,953 --> 00:10:51,793 So one of our the main requirement is we need a single source of truth but we 102 00:10:51,793 --> 00:10:57,173 We also need to make sure that that single source of truth is easy to change 103 00:10:57,173 --> 00:11:01,873 and easy to change for people who are not necessarily developers. 104 00:11:02,353 --> 00:11:08,013 Because we want to be able to work with our designers to make it easier for 105 00:11:08,013 --> 00:11:11,973 them to implement their vision of how things should look. 106 00:11:17,792 --> 00:11:23,712 On the other hand, I also have some requirements, and those come from my side, 107 00:11:23,832 --> 00:11:28,692 from the technical side, because I want to make, if I'm going to work on this, 108 00:11:28,732 --> 00:11:30,492 if I'm going to build something for this, 109 00:11:30,752 --> 00:11:37,112 I want to make sure that I can build something that is optimized for our target. 110 00:11:37,112 --> 00:11:44,012 So if I'm building something and I want to target Qt Quick, I want to have something 111 00:11:44,012 --> 00:11:48,432 that uses Qt's quick hardware acceleration to render. 112 00:11:48,752 --> 00:11:56,272 If I'm using it in, I don't know, if we're going to use it in a crazy idea, 113 00:11:56,352 --> 00:12:01,912 in a game engine using Vulkan, I want it to be able to use Vulkan internally. 114 00:12:04,112 --> 00:12:08,212 So that's one of the things. the other requirement is that single source of 115 00:12:08,212 --> 00:12:10,452 truth should not have any logic. 116 00:12:11,332 --> 00:12:16,392 And this is a technical requirement from my side because if we don't have logic 117 00:12:16,392 --> 00:12:25,152 in there, it means that we can do a lot more, lots more optimization on the library side, 118 00:12:26,032 --> 00:12:31,112 with this, on this input format so that we can do cache, more intelligent caching, 119 00:12:31,652 --> 00:12:36,632 that doesn't need things like, oh, hey, state changed, so I need to call back 120 00:12:36,632 --> 00:12:39,392 into whatever gives me this information. 121 00:12:41,772 --> 00:12:46,052 And needs to ask that to re-render something. No, you can just say, 122 00:12:46,092 --> 00:12:48,372 okay, state changed, here, have this different thing. 123 00:12:50,282 --> 00:12:55,662 And it needs to be flexible enough that we can define custom types. 124 00:12:56,782 --> 00:13:05,662 Because within KDE, we have the Kirigami library, which implements a whole bunch 125 00:13:05,662 --> 00:13:07,802 of custom controls on top of Qt Quick. 126 00:13:08,202 --> 00:13:10,622 And they are all styled like Breeze. 127 00:13:11,142 --> 00:13:16,702 And there is no way for you, or well, there is a way, but there is practically 128 00:13:16,702 --> 00:13:22,022 almost no way for you to restyle those into a different style. 129 00:13:22,282 --> 00:13:32,382 So if you go and use a Kirigami application under GNOME, it will look like Breeze, at least partially. 130 00:13:37,902 --> 00:13:49,242 So, with those requirements listed, let's look at how I got to where we are currently. 131 00:13:49,622 --> 00:13:53,042 So at some point while working on this 132 00:13:53,042 --> 00:13:57,102 entire thing, which has been a long process, I came up with this idea. 133 00:13:57,322 --> 00:14:08,262 What if we separate things? What if we say, hey, we have some kind of definition 134 00:14:08,262 --> 00:14:10,802 that defines how things should look. 135 00:14:11,002 --> 00:14:20,242 And then we have an intermediate layer where that input format can get transformed 136 00:14:20,242 --> 00:14:21,642 into that intermediate layer. 137 00:14:21,642 --> 00:14:29,602 And then we have an output format that consumes that intermediate layer instead of the input format. 138 00:14:30,162 --> 00:14:35,902 The main difference this makes is that if something needs to change, 139 00:14:36,042 --> 00:14:41,542 if we want a different input format or whatever, we don't need to change the output format. 140 00:14:41,762 --> 00:14:47,502 If we want to add a different output format, we don't need to bother with the input format. 141 00:14:50,570 --> 00:14:54,250 So that was my idea that I had at some point. 142 00:14:54,390 --> 00:15:02,910 And I basically came up with, hey, could we use this to build something where 143 00:15:02,910 --> 00:15:08,270 we use CSS as an input format, 144 00:15:09,710 --> 00:15:16,190 read a CSS file, read some definitions from that CSS file, and use that to style 145 00:15:16,190 --> 00:15:20,070 both a Qt Quick application and a Qt Widgets application. 146 00:15:21,250 --> 00:15:28,070 So I built a proof of concept of that a few years back at this point, 147 00:15:28,190 --> 00:15:34,330 proving that, hey, yeah, maybe we can actually do this. 148 00:15:34,570 --> 00:15:42,350 So I built this using a CSS parser that I found somewhere on the Internet, which is its own issue. 149 00:15:42,350 --> 00:15:48,290 I'll get into that a bit later, and build this very minimal intermediate layer 150 00:15:48,290 --> 00:15:56,470 that this CSS got converted into, and then build a Qt Quick style using some of our standard stuff. 151 00:15:57,350 --> 00:16:02,830 But using the information that came out of this intermediate layer to render 152 00:16:02,830 --> 00:16:06,950 a button that looks somewhat like how Breeze would style it. 153 00:16:06,950 --> 00:16:12,750 And then on the other side, I built a cue style that used that same information 154 00:16:12,750 --> 00:16:18,670 and then did the same thing and ended up rendering a button that looked mostly 155 00:16:18,670 --> 00:16:20,450 the same to the Cued Quick side. 156 00:16:21,190 --> 00:16:26,290 There's some bits that are not entirely the same, but that was mostly because 157 00:16:26,290 --> 00:16:32,550 I ended up not wanting to spend that extreme amount of time to get that rendering right. 158 00:16:32,550 --> 00:16:37,230 Right so what 159 00:16:37,230 --> 00:16:41,950 can we learn what could we learn from that proof of concept well most importantly 160 00:16:41,950 --> 00:16:47,730 my the core of my idea seems like it would be work and it would be possible 161 00:16:47,730 --> 00:16:54,950 to have something where we have a single input format and two or more output formats. 162 00:16:56,750 --> 00:17:00,130 Of course, it also means that, hey, 163 00:17:00,390 --> 00:17:07,050 yeah, okay, so we have this, but it means that we're basically going to need 164 00:17:07,050 --> 00:17:13,610 to rewrite the entire set of how we do our styling within KDE, 165 00:17:13,810 --> 00:17:16,850 which is going to be a lot of work. 166 00:17:19,350 --> 00:17:28,350 Yeah um and also something from the input from the proof of concept as i mentioned it was using css. 167 00:17:30,570 --> 00:17:36,770 Css is a problem mainly because there are no good css parses out on the internet 168 00:17:36,770 --> 00:17:41,970 at least not for what i want to do here like there's there are plenty of css 169 00:17:41,970 --> 00:17:46,110 there's plenty of css parses around like in web browsers and stuff, 170 00:17:46,330 --> 00:17:54,610 but none of them are available as a C++ library where I can get a parsed tree 171 00:17:54,610 --> 00:17:58,610 of what's in a CSS file because most of them go like, 172 00:17:58,750 --> 00:18:04,530 oh yeah, here have a styled thing already or stuff like that. 173 00:18:06,590 --> 00:18:11,010 And because, as I mentioned, it's all going to be a lot of work. 174 00:18:11,010 --> 00:18:17,030 So we need some way of splitting up this thing, because rather than building 175 00:18:17,030 --> 00:18:20,190 this monolith somewhere in 176 00:18:20,190 --> 00:18:25,130 a dark corner of KDE and then at some point going, look, here is my thing. 177 00:18:25,250 --> 00:18:27,530 It's done and it's going to be awesome. 178 00:18:27,770 --> 00:18:34,290 And then the real world hits it and it turns out to shatter that entire monolith. 179 00:18:34,290 --> 00:18:39,670 With, um, we need to be able to do this in a more intimate, um, 180 00:18:40,070 --> 00:18:49,210 step step by step way so that we can prove parts of the implementation are correct. 181 00:18:52,704 --> 00:19:02,504 So this proof of concept was done, I think I presented it to people during Academy 2022. 182 00:19:04,424 --> 00:19:10,224 And then it kind of didn't go anywhere because of various reasons. 183 00:19:10,564 --> 00:19:16,664 But I did mostly because I didn't have the time for it. 184 00:19:17,364 --> 00:19:24,704 I did spend on occasion some time on, hey, okay, let's make a production version of this. 185 00:19:24,944 --> 00:19:30,824 How do I go about this? And this is how the project that I now call Union came about. 186 00:19:32,844 --> 00:19:37,144 And it's meant to become this single source of truth, 187 00:19:37,784 --> 00:19:46,564 styling engine that we can use to get our styling into a shape that where our 188 00:19:46,564 --> 00:19:48,664 designers aren't running away screaming. 189 00:19:52,824 --> 00:19:57,784 So, again, I go back to how do we go about this. 190 00:19:58,064 --> 00:20:01,604 At some point when we were discussing this, 191 00:20:02,164 --> 00:20:08,524 a fairly smart guy who you may have heard about called David Edmondson suggested, 192 00:20:09,064 --> 00:20:17,964 hey, what about doing it as, what about just reimplementing the way Plasma is 193 00:20:17,964 --> 00:20:20,944 styled using this engine, 194 00:20:21,964 --> 00:20:27,564 so that we know what the input format is, we know what the output format is, 195 00:20:27,704 --> 00:20:36,524 and we have a way of, a thing where we can focus on that intermediate layer, because a lot of stuff, 196 00:20:37,944 --> 00:20:42,704 depends on that intermediate layer, and if that intermediate layer sucks, 197 00:20:43,004 --> 00:20:44,744 then the entire thing will suck. 198 00:20:47,096 --> 00:20:51,676 So that's basically what I've been doing for the past several months, 199 00:20:51,836 --> 00:20:58,096 because finally someone came with, hey, I also want this. 200 00:20:58,136 --> 00:21:00,676 Also, I'm going to give you guys some money for this. 201 00:21:01,356 --> 00:21:06,456 So now I suddenly do have the time as part of my day job to work on this. 202 00:21:06,556 --> 00:21:09,416 So it's finally making progress, luckily. 203 00:21:10,516 --> 00:21:17,136 So what does that look like? Well, it looks like this. The left two buttons 204 00:21:17,136 --> 00:21:20,736 are being rendered by Union, are using styling from Union. 205 00:21:20,916 --> 00:21:23,556 The right two buttons are using styling from Plasma. 206 00:21:24,756 --> 00:21:29,076 It doesn't look any, well, apart from the icon, ignore that, 207 00:21:29,276 --> 00:21:31,656 it doesn't look any different at the moment, 208 00:21:32,696 --> 00:21:36,056 which is exactly the intention, because right now, 209 00:21:36,096 --> 00:21:39,416 what we are trying to do is recreate Plasma styling, 210 00:21:39,416 --> 00:21:42,216 styling because that's what now we know 211 00:21:42,216 --> 00:21:45,096 we know what that needs to look like so we 212 00:21:45,096 --> 00:21:47,776 need to come up with all the constructs to 213 00:21:47,776 --> 00:21:50,816 make sure that with that separation of 214 00:21:50,816 --> 00:21:54,736 concerns about having the inputs layer which 215 00:21:54,736 --> 00:22:01,076 now reads plasma svg that converts all that into this intermediate layer and 216 00:22:01,076 --> 00:22:06,056 then goes into a separate cute quick style that reads makes use of that intermediate 217 00:22:06,056 --> 00:22:11,656 layer and puts out something that actually looks like what Plasma does. 218 00:22:13,956 --> 00:22:17,976 So some implementation details about that. 219 00:22:19,496 --> 00:22:28,736 We now have a core library that basically is built around a concept of a theme 220 00:22:28,736 --> 00:22:32,256 where a theme has a collection of style rules. 221 00:22:32,256 --> 00:22:37,796 And a style rule is well 222 00:22:37,796 --> 00:22:40,396 I'll get into that in a moment but it has a 223 00:22:40,396 --> 00:22:45,836 collection of style rules and selectors and then we have an input plugin input 224 00:22:45,836 --> 00:22:53,396 plugins currently only one one that reads plasma SVGs and converts that into 225 00:22:53,396 --> 00:22:58,776 a bunch of style rules and then we have an acute quick style 226 00:22:59,016 --> 00:23:04,616 implementation that feeds information into the theme and with that information 227 00:23:04,616 --> 00:23:11,156 selects which of those style rules apply to the current thing that it's trying to render. 228 00:23:14,148 --> 00:23:19,068 So style rules, I mentioned that. 229 00:23:19,208 --> 00:23:24,948 Style rules are which properties do apply to this element. 230 00:23:27,048 --> 00:23:30,828 That's the most generic description I can give you of this. 231 00:23:32,728 --> 00:23:40,348 And importantly as well, style rules have a selector. that selector determines 232 00:23:40,348 --> 00:23:45,768 what kind of elements this style rule applies to. 233 00:23:46,048 --> 00:23:54,548 So you can have something that says, hey, my text color should be red and this 234 00:23:54,548 --> 00:23:56,768 should apply to any button. 235 00:23:57,408 --> 00:24:06,828 And if we have a button that is currently focused, rather than using red, it should become blue. 236 00:24:08,088 --> 00:24:11,288 These kind of things are encoded using the style rules. 237 00:24:12,028 --> 00:24:18,068 And they are effectively, they form a stack where the topmost properties read 238 00:24:18,068 --> 00:24:22,108 first, and if there's no value in the current style rule for that, 239 00:24:22,168 --> 00:24:23,548 the next one is used, etc. 240 00:24:25,408 --> 00:24:29,468 For those who have experience with CSS, this may sound very familiar. 241 00:24:29,468 --> 00:24:39,268 That is kind of intentional, partly because I was inspired by CSS and partly 242 00:24:39,268 --> 00:24:42,848 because I still want to be able to use CSS eventually, 243 00:24:43,248 --> 00:24:45,828 but that's also a thing I got into. 244 00:24:52,588 --> 00:24:55,528 Um sorry how much time is 245 00:24:55,528 --> 00:25:01,068 left 15 minutes okay um so 246 00:25:01,068 --> 00:25:04,388 that's the current state what's next 247 00:25:04,388 --> 00:25:07,368 um i want to finish up this plasma 248 00:25:07,368 --> 00:25:14,368 style thing and uh basically get that into a state where we can say hey we deprecate 249 00:25:14,368 --> 00:25:20,088 uh plasma controls uh the plasma specific implementation of the styling and 250 00:25:20,088 --> 00:25:25,148 use it use union instead so that we can get some real-world testing of this, 251 00:25:27,088 --> 00:25:33,668 we need to implement the Qt widget side which is going to be its own dragon to slay. 252 00:25:36,348 --> 00:25:39,108 And we need to decide on a 253 00:25:39,108 --> 00:25:42,148 new input format because CSVG is not meant as 254 00:25:42,148 --> 00:25:45,468 the final input format as I said 255 00:25:45,468 --> 00:25:48,988 before I still really prefer using would 256 00:25:48,988 --> 00:25:52,268 like to use css but that's tricky 257 00:25:52,268 --> 00:25:56,048 with library things there 258 00:25:56,048 --> 00:25:59,648 might be a solution in using a rust css parser 259 00:25:59,648 --> 00:26:09,248 but yeah that's still in the in the investigative state um we also need to do 260 00:26:09,248 --> 00:26:15,988 a bunch of application integration because union assumes that a bunch of the 261 00:26:15,988 --> 00:26:17,708 information comes from from the application, 262 00:26:17,948 --> 00:26:21,928 next to what the style can already provide. 263 00:26:22,568 --> 00:26:29,128 But as a simple example, we have this header area in our applications. 264 00:26:30,008 --> 00:26:34,688 With Union, my intent is that the application will provide us information about 265 00:26:34,688 --> 00:26:38,128 what is defined as its header area. 266 00:26:41,074 --> 00:26:45,954 And there are some other things. We have a bunch of things where we use styling, 267 00:26:46,334 --> 00:26:49,434 breeze-like styling, and as 268 00:26:49,434 --> 00:26:56,354 well, mentioned here, GTK is a thing where we currently have a custom CSS. 269 00:26:56,734 --> 00:27:00,534 We might be able to use this to generate a CSS style. 270 00:27:01,594 --> 00:27:08,554 But that depends also on whether that GTK styling is actually maintainable, 271 00:27:08,674 --> 00:27:14,314 because from the GTK side there's a lot of push about, hey, don't team my apps and all that stuff. 272 00:27:17,174 --> 00:27:23,174 So with that, I come to the end and would say, any questions? 273 00:27:40,954 --> 00:27:48,174 All right, so specifically, when it comes to PlasmaSight, you also mentioned this. 274 00:27:48,314 --> 00:27:54,374 So we have these SDGs with a bunch of elements that have truly established names. 275 00:27:54,654 --> 00:27:57,694 The code on the PlasmaSight knows how to use them. 276 00:27:57,794 --> 00:28:03,134 That's the component. but can you walk me through where does that match up happen 277 00:28:03,134 --> 00:28:04,334 in the SQ implementation? 278 00:28:04,774 --> 00:28:09,154 Because you mentioned the output plugin that we currently have is a generically 279 00:28:09,154 --> 00:28:12,094 quick one. Where's the sort of Plasma knowledge? 280 00:28:12,414 --> 00:28:14,634 That's on the inputs plugin side. 281 00:28:15,194 --> 00:28:21,814 So in the case of Plasma SVG, we actually have two layers there because we have 282 00:28:21,814 --> 00:28:29,754 a bunch of definitions in YAML that define which elements should be used for certain controls. 283 00:28:37,851 --> 00:28:50,251 So, could you explain how your work on this has any implications about using a Qtab, 284 00:28:51,131 --> 00:28:54,311 in a desktop environment that is not Plasma? 285 00:28:54,791 --> 00:29:03,451 So, the intent is eventually that we can have different input format, 286 00:29:03,551 --> 00:29:09,691 different input styles that implement platform specific styles. 287 00:29:10,071 --> 00:29:20,411 So rather than having to rely on a bunch of different elements coming from different styles, 288 00:29:20,731 --> 00:29:24,871 we have a single source of truth that might be Breeze, 289 00:29:25,031 --> 00:29:30,051 but it also might be a window specific thing or 290 00:29:30,051 --> 00:29:33,271 a gdk specific thing or whatever or 291 00:29:33,271 --> 00:29:38,731 uh and and i've not mentioned this intentionally but if someone wants to go 292 00:29:38,731 --> 00:29:45,351 and do third-party implement a third-party theme they can style the entire uh 293 00:29:45,351 --> 00:29:47,711 the intention at least is that 294 00:29:47,711 --> 00:29:51,791 they can style the entire plasma desktop using their own custom theme. 295 00:29:56,871 --> 00:30:03,011 Have you looked into the integration with the Q-Palette and the Palette's configurations 296 00:30:03,011 --> 00:30:06,331 for Qt application together with this? 297 00:30:06,471 --> 00:30:12,251 Because Qt application can also provide their own styling information using the Palette. 298 00:30:13,291 --> 00:30:16,891 Yeah um right now it doesn't 299 00:30:16,891 --> 00:30:21,671 do that because the plasma styling doesn't do that it is a thing that we will 300 00:30:21,671 --> 00:30:28,191 need to look into especially for Qt widgets and Qt style we do actually have 301 00:30:28,191 --> 00:30:34,151 some experience with this already on the with the Qt desktop style Qt quick 302 00:30:34,151 --> 00:30:35,331 desktop style and things 303 00:30:35,411 --> 00:30:38,571 like that, we already do some integration with Qt Palette. 304 00:30:39,251 --> 00:30:46,211 Unfortunately, it became harder with Qt 6 because Qt Palette in Qt Quick moved 305 00:30:46,211 --> 00:30:49,431 from being a Qt Palette to a Qt Quick Palette. 306 00:30:50,511 --> 00:30:56,131 That's a different discussion, but yeah, that's definitely one of the things 307 00:30:56,131 --> 00:30:57,531 that we do intend to support. 308 00:31:01,221 --> 00:31:10,441 Hello! It happens that we have a CSS style in Qt Widgets, which I assume you have looked at. 309 00:31:11,501 --> 00:31:16,281 That includes a CSS parser and also a similar architecture around rules from 310 00:31:16,281 --> 00:31:17,441 what I understood from you. 311 00:31:18,601 --> 00:31:22,521 One of the challenges we have for the CSS style or the style sheet style in 312 00:31:22,521 --> 00:31:29,321 Qt is of of course, that it tries to know which aspects of the UI you have styled 313 00:31:29,321 --> 00:31:33,321 using CSS versus where it should fall back to the default style. 314 00:31:33,501 --> 00:31:39,681 Do you plan to do something similar magic or do you agree with me that by not 315 00:31:39,681 --> 00:31:42,721 having any kind of default behavior, everything is unstyled, 316 00:31:42,781 --> 00:31:46,201 if it's not explicitly styled, we just draw everything as dumb rectangles, 317 00:31:46,261 --> 00:31:48,261 we can remove move a lot of that complexity. 318 00:31:48,721 --> 00:31:55,601 So, uh, I agree with you in there that no, we, I am not planning on any fallback behavior there. 319 00:31:55,901 --> 00:32:02,361 Um, or at least no, no low level, like per properties fallback stuff. 320 00:32:02,681 --> 00:32:06,921 We might be able to do something with, with higher level fallbacks, 321 00:32:07,001 --> 00:32:13,561 but, um, yeah, the, the intent is not to have complicated fallback mechanisms there. 322 00:32:23,321 --> 00:32:31,841 On the topic of CSS as an input format, CSS is quite powerful with animations and logic constraints. 323 00:32:32,421 --> 00:32:37,021 How much do you actually want to support Fromset, what is the large feature set? 324 00:32:38,981 --> 00:32:43,381 That's currently an open question. It's something that needs to be investigated 325 00:32:43,381 --> 00:32:46,261 when we're actually developing a CSS input format. 326 00:32:49,621 --> 00:32:53,361 Animations are something that we will want to support simply because we want 327 00:32:53,361 --> 00:32:59,821 to be able to use that for Breeze stuff, but maybe not all the types of animation. 328 00:33:00,661 --> 00:33:03,901 I'm mostly thinking like transitions we would want to support, 329 00:33:04,161 --> 00:33:07,561 but maybe not completely freeform animations. 330 00:33:08,101 --> 00:33:12,501 And there's also things like media queries and stuff, what do you do with that. 331 00:33:13,281 --> 00:33:21,481 Advanced selectors Yeah, you're completely right, CSS, especially what's becoming 332 00:33:21,481 --> 00:33:25,581 CSS4, is quite complex and large. 333 00:33:25,781 --> 00:33:34,601 And we'll have to see what we can support, also what needs to be supported. 334 00:33:44,589 --> 00:33:48,169 You mentioned something about custom controls. 335 00:33:48,549 --> 00:33:53,529 How do you currently do that in using Qt Quick style? 336 00:33:53,649 --> 00:33:59,689 Because you need to provide this template for all the controls that we currently support. 337 00:34:00,029 --> 00:34:02,729 So what is your solution for these custom ones? 338 00:34:03,709 --> 00:34:09,649 So as I mentioned, currently the solution is that we style them as Breeze. 339 00:34:10,609 --> 00:34:13,849 And we don't we we there is 340 00:34:13,849 --> 00:34:20,429 a an in on the kirigami side we do have a construct where we do support like 341 00:34:20,429 --> 00:34:26,649 having a template where you that you can re-implement but in practice basically 342 00:34:26,649 --> 00:34:33,609 almost no one does that because it's it's just a lot of work and ends up being very complex, 343 00:34:34,209 --> 00:34:40,689 So the end result is basically that we always have Breeze-styled custom controls, unfortunately. 344 00:34:55,964 --> 00:34:59,584 So so um previously you 345 00:34:59,584 --> 00:35:02,504 said there was be like no fallback behavior and yeah 346 00:35:02,504 --> 00:35:05,484 i'm sure that makes sense uh but would it be possible 347 00:35:05,484 --> 00:35:08,544 for like a user to say oh i 348 00:35:08,544 --> 00:35:11,464 want my theme to inherit from this 349 00:35:11,464 --> 00:35:14,584 other theme like let's say a user says i 350 00:35:14,584 --> 00:35:17,584 like most debris but i want to change this 351 00:35:17,584 --> 00:35:21,224 bit it yes that uh will be 352 00:35:21,224 --> 00:35:24,504 uh at least uh i do intend to 353 00:35:24,504 --> 00:35:30,204 support things like that um it will be up to the input formats on how that works 354 00:35:30,204 --> 00:35:35,724 like uh with css it might just end up being something like hey import breeze 355 00:35:35,724 --> 00:35:41,844 and in the css file and then override some rules um but that that it's it's 356 00:35:41,844 --> 00:35:43,384 one of those areas where it, 357 00:35:43,464 --> 00:35:47,584 I think it is up to the input format to determine the best solution. 358 00:35:54,444 --> 00:35:59,784 Uh, have you looked into the GTK CSS styling, if it's something like that can 359 00:35:59,784 --> 00:36:04,144 be used, uh, so we at least get a bunch of themes, uh, for free automatically 360 00:36:04,144 --> 00:36:06,824 if you use the same CSS style. 361 00:36:07,704 --> 00:36:15,804 Yeah. You're, you're not the first one to mention that. I have looked at that 362 00:36:15,804 --> 00:36:20,724 and basically concluded that it's probably not feasible for us, unfortunately. 363 00:36:21,864 --> 00:36:29,544 And also partly because of current attitude of GTK developers towards this. 364 00:36:31,384 --> 00:36:38,644 So I am quite hesitant to go and reuse something where they say, 365 00:36:38,764 --> 00:36:41,304 no, no, this is ours and you must not touch this. 366 00:36:41,944 --> 00:36:45,244 I was hoping to revive Advaita Q, but sadly no. 367 00:36:53,435 --> 00:37:00,595 While the implementation part is another story for this architecture specifically, 368 00:37:01,615 --> 00:37:09,415 while GNOME and GTK sites is a little different on that for this intermediate 369 00:37:09,415 --> 00:37:17,995 layer would you consider contributions that cover more than the Qt for like, 370 00:37:18,515 --> 00:37:21,275 other desktops, like Cinnamon, et cetera, 371 00:37:22,075 --> 00:37:29,695 to make it from KDE into a more free desktop thing, possibly? 372 00:37:30,175 --> 00:37:34,415 I mean, if there's interest there, yes, I would definitely consider them. 373 00:37:34,795 --> 00:37:42,035 I am open to have this integrated in more layers, also to make it easier to 374 00:37:42,035 --> 00:37:45,075 run KDE stuff on Cinnamon or something. thing. 375 00:37:45,815 --> 00:37:48,255 So I would totally be open to that. 376 00:37:49,655 --> 00:37:55,175 We need to figure out what the right place for such things would be. 377 00:38:04,435 --> 00:38:07,915 So in my mind, I'm kind of getting hung up on the details. 378 00:38:08,435 --> 00:38:14,955 On the notion of custom controls, I'm curious if you can give a little hint 379 00:38:14,955 --> 00:38:19,395 at how you plan for that intermediary layer to be extensible. 380 00:38:19,655 --> 00:38:25,035 Because you mentioned one of your requirements is that the input side should be logic-free. 381 00:38:25,195 --> 00:38:27,875 But in your re-implementation, that's currently not the case, right? 382 00:38:27,935 --> 00:38:31,855 Because you have the input plugin reading the SVG doing the magic translation 383 00:38:31,855 --> 00:38:33,755 of this should be a task manager button. 384 00:38:33,875 --> 00:38:36,495 These are the element names to the intermediary thing. 385 00:38:36,655 --> 00:38:43,095 But in your future input format, the input would be more generic so how do you 386 00:38:43,095 --> 00:38:46,875 transport the notion that there is not just, 387 00:38:47,475 --> 00:38:51,415 a button but there's also a specialization which is let's say a task manager 388 00:38:51,415 --> 00:38:56,755 button which doesn't occur anywhere else into that like how do you extend that 389 00:38:56,755 --> 00:39:00,975 i'm curious about that So, I'll correct you on one thing. 390 00:39:04,395 --> 00:39:10,015 The input format, the format needs to be logic-free. 391 00:39:10,195 --> 00:39:14,015 It's not the plugin that needs to be logic-free. You don't consider the plugin 392 00:39:14,015 --> 00:39:19,215 to be the... No, the plugin is the thing that translates the input format into 393 00:39:19,215 --> 00:39:21,435 the intermediate format. Okay. 394 00:39:22,675 --> 00:39:27,975 Yeah, and I ran out of time. I'll gladly talk about it in detail with you. 395 00:39:28,135 --> 00:39:30,875 I can actually show you some code. 396 00:39:40,375 --> 00:39:42,075 That was very great. Thank you.