 Can you see my screen? Yes. Yes. Oh, great. So maybe my presentation will be answered for the previous question, because I'm going to talk about reusing the sidebar on phones. And this is the same mechanism which can be used for dialogues. So over one year ago, I think that our online app for mobile was really poor, because it was a simple viewer and had only basic functionality for editing, for example, color of the text or just bolding it. And there was not too much features for inserting new complex objects or editing, for example, charts. But over last year, it completely was changed, because we almost rewrite our UI. And thanks to reusing the sidebar, we made online a powerful fully-featured editor. As you can see on these screenshots, we can now edit even a complex chart or do other actions with text. We also introduced a lot of new menus. We added new color picker, which is much easier to use on a touch device with a small screen than a drop-down. We added functionalities for inserting complex elements, like tables, charts, comments, and other objects. We also redesigned the hamburger menu. And the main idea was to not write a new code about UI for the online, but reuse existing functionality from the server. So in the desktop application, we have already sidebar, which is context-dependent. So when you select a text, you see text properties. But when you select the shape, you can see other properties for editing shapes. And it's also well-organized into the backs and panels. For the desktop case in online, we transfer that sidebar as an image. But for mobile use, it's not a good idea because the sidebar could have very small icons. And we cover the full screen. So we had an idea, which is very easy. We just transformed the existing UI component, which is the sidebar. We transform it into the description of the structure and the values inside in JSON format. Then we sent it to the client. And in the web browser, we build the new HTML-based user interface. On the core side, we generate the JSON from the tree structure of widgets. So like we can see here, for properties that we have a few child panels, and each panel has its own elements. This is very easy to structure to turn into text description into a JSON format. So for every control we have in LibreOffice, every type of control, we introduced new method, which is called dump as property tree, which generates JSON from it. And for containers, we also added functionality to dump also its children. So if, for example, we have container with text box inside, and we will use dump as property tree method on that container, we will get the result visible on the right side. So for every control, we add standard properties like ID and type of the control and also children. But for particular regions, we have also specific properties like the text value or enabled state. For children inside containers, we also export the position in the container. So if we have agreed, we know the coordinates of every widget in the original dialog. For the sidebar, we generate this JSON inside of sidebar docking window. And we send it to the client using the LibreOffice kit callback mechanism with the correct ID of the center window. We had previously a small performance issue because of using the boost library for the tree structure. But this was replaced later with JSON writer by null. And after we send that to the client on the online side, we have two main components which are using the JSON. First, we had to create the container for the sidebar. So as you can see, it's the small frame on the bottom of the screen. It's called mobile result in our code. And this container handles the header. So it shows the navigation like back arrow or exit button. It also can show tabs if needed. And also handles the traverser for the menu structure because we can have submenus, like in this case, for example, for table menu. On mobile devices, at least for Android devices, we have back button. So to implement also going back functionality for this button, we used history API in the browser. So when we open the menu or go to the next level, we always put the states to the history. And then when back button is pressed, we go level up or we close the panel if this is the main view. The next important component in the online side is Builder. Builder receives the JSON from the server and then parses it and builds the interface from the description. So we don't have to implement every dialogue in the online code. But we have this engine for building correct interface from the description of the structure and values. So in Builder, we have two registers. One is for control handles where we register building functions for every type of supported regions. And also we have second register with special cases for particular unit commands. So for example, when we have color pickers, in the normal sidebar, they were creating pop-up windows with color picker. But on mobile, we wanted to introduce something better. So we use special custom widget for every unit command, which has the possibility to select color for text or shape. And how it looks. When we have only two decks in the JSON, two panels, then we show them as mobile wizard with tabs. So in this example, there is character tab and paragraph tab. Or when we have more panels in the sidebar, we add submenus. So you can see on the right side, there is a video where we have three panels, area, line, position, and size. And we can explore them for single buttons in the sidebar. We have handler with which tags the unit command and creates icon in the mobile wizard. The mobile wizard, which after it's clicked by a user, sends the unit command. And also, it follows the state of the unit command. So when we have bold selected text, which is bolded, we see that bold icon is highlighted. Other simple widgets are checkboxes and radio buttons. As you can see, they are presented in mobile style. So we have checkmarks on the right side, where it's very easy to tap using just one finger. They have not a complex JSON structure. They have only one special property, which is checked state. Color pickers, like I said, we wanted to replace the existing split buttons with drabdoms. So we created custom handler for unit commands selecting the color. And we have this nice color picker with big ties, which is very easy to tap even on smaller screens. Other more complex controls are metric boxes, which have more properties. They have constraints, like minimum and maximum values. They show the unit on the right side. And on the left side, we have always the small icon, which tells us what property we change. We have also the control buttons, which are used to increase or decrease the value. And one of the most complex widgets are list boxes. We show them as submenus. So we can enter the submenu where we can select the value. In the JSON structure, we send all the entries, list of the entries, and also list of selected entries. So we can later select the current value inside. And also we can show the preview even next to the header of this submenu. Of course, we need two-way communication, not only from the server, not only from the sidebar to the web browser, but also from the web browser to the sidebar to notify the sidebar about changes that the user performs. So we catch the HTML events when the user, for example, clicks on the plus button next to the metric box. Then we send the dialog event to the server with correct window ID pointing to the correct sidebar window. And we send the ID of the control, the type of all that control, and command, which was performed, and some additional data. On the backend, we use the test UI framework, which is used for Python UI testing in LibreOffice. And we execute the actions in the real sidebar. After event is processed, we generate new JSON, and we send that back to the client. This approach is not perfect because we send the new JSON only on requests when user performs some actions. But in some cases, when we have asynchronous updates in the dialog, we probably not receive any new JSON. So there is another interesting mechanism in the LibreOffice code. It's called the belting. It was implemented by Kailan McNamara for showing the dialogues in the native GTK using the native GTK free UI components. And this mechanism adds some abstraction level to the between dialog code and the native user interface. And I wanted to use that for my work. So instead of using GTK free, I wanted to use my HTML controls and the middle layer will send the notifications between the dialog and the web browser. When we take a look how this middle layer looks, it's set of wrappers and standard controls. And every wrapper have methods for all the actions we can perform on that particular widget. And also it has callbacks, which can be called to notify the dialogue about some user actions. So it's perfect for our use case because we can inject JSON generation in every method which modifies the widget. And also when a client will send us a message about some user actions, we can call the callbacks to inform the dialogue about the changes. In normal case, we have dialogue which creates the builder and builder creates the native UI. Later dialogue requests references to the welded wrappers and all the communication goes through this wrapper. So in our case in online, it will look like this. So we will not have the native controls on the server side but on the client side. And our wrappers will send over web sockets all the notifications from the server to the client. And also we will receive notifications from the client. And then pass it to the dialogue code. I already used that mechanism in for porting few dialogues for mobile view. I placed my code in vcl.js dialogue where I implemented the new builder and also wrappers for standard controls. When we open some dialogues like for example watermark dialogue, I inject my JS instance builder which later creates wrappers which perform the further communication. And also I created executor which handles the messages from the server and uses the welded wrappers to notify dialogue about changes. I think this is the same mechanism we can use in the sidebar so it will improve the code. This is now possible because if I remember correctly on current master, the sidebar is fully welded so this should work out of the box. If you want to check the new UI on mobile, you can download the collaboration from Apple Play Store and try it on your own. Thank you for listening. I can ask a question. I wrote it in the chat but to repeat it here, you showed the sidebar color picker simplified version and I just wonder what happens with non-standard colors. We did the trick in desktop to store it on a special palette but we have much more ways to deal with it. What happens to the sidebar when you have a non-standard color? That question. I don't know. I think, of course, in the menu when we see the, for example, font color next to that entry, we see the preview of a selected color. If there will be some non-standard color, we will see the correct color in that area but later when we tap on that sub-menu, we will see our standard color picker so we will be able only to select some predefined colors. We don't support new palettes. I think I get it. It is just nothing selected in this dialogue and you can just choose from the standard colors but it's not ignoring what the user has assigned to it somewhere else and there are dialogues. One of the later pictures shows the drop-down with a hex value of the color. In this case, it works anyway. It makes sense. Thank you. Any more questions? Yes, I have a question. When you use this sidebar from the Android release of the iOS release on the online, can you mix there, for example, use the correct color picker because there's enough space or how would it work? I'm sorry, I don't understand the question. Okay, now on the online release, you use an image of the side of the LibreOffice sidebar but when you say you want to use this new approach also on the online release, first, would it be useful or possible or would it be a step in the wrong direction? Sorry, you are asking if we want to reuse the JavaScript-based sidebar also on the desktop online, yes, not only on mobile. Yes, yes. And you are asking about the drop-downs with color picker. If they will be like the mobile ones or if we will implement some way to show the correct sidebar, like on the desktop, in the LibreOffice desktop application, yes? Yes. I think it's quite hard to... I had some problems implementing that mechanism because the app was crashing when I was selecting some non-sundervalued. Okay. So I think we will have separate pallets in the online desktop done in the desktop application. Okay. Okay. Because also to unify the user interface, we already have color picker for the desktop case. It's a drop-down. So probably when I will port the sidebar, JavaScript sidebar also for the desktop online, I will reuse the existing one drop-down. Okay. From the toolbar. Yes, because the toolbars are really great. Also, for example, the font selector is really great compared to the one from the sidebar. Yes, yes. For example, I will reuse this contrast from the toolbar view. For example, the drop-downs always have a search on top. So it's very comfortable to search after font names and so on. It's really great there. Yes. Good work. Thanks a lot. Thank you.