Anatomy of document editors: a common code for online and offline versions of ONLYOFFICE editors
If someone asked us what day it is today, we would answer that today is the Big Day. The day when we finally release the desktop editors ONLYOFFICE . Those that work without a browser / Internet and send the document directly to the printer.
Yes, we are the guys who for a long time were engaged exclusively in online editors, and then made offline applications. First, despite the growing popularity of online editors, most users continue to prefer desktops. Secondly, we ourselves have long wanted to get away from the limitations of the browser and speed up the work with editors.
The main feature of our desktop editors in their relationship with online editors - they are united by a common source code. In this article we will explain a little why we decided to make desktops in this way and reveal the secrets of their anatomy, namely - how they differ from the online version, how they are arranged and what we plan to change in the future.
')
In this still a bit of the introductory part of the text, we recall that we really love online editors, but not always. Some moments are very sad. Look at the confused face of a user who just tried to copy something from his document, but was faced with an urgent recommendation to use the keyboard? And this poor fellow who just wanted to print, and now downloads pdf? Or is it unfortunate with chopped off the Internet? In general, everyone has already guessed where we are going. Desktop editors have undoubted advantages, and here are the ones:
So, we were sure that we wanted to make desktops. But we had to answer the question: how?
Variant which we refused : native applications. Although we also believe that nothing could be cooler than the native application, force majeure circumstances forced us to abandon this idea due to the complexity and cost of its implementation.
If we chose this option, we would need to rewrite the code of the editors and the entire visualization. In addition, in the future there would be a question of synchronizing updates with the web version of the editors. We would get two codes that do the same thing and would do double work, correcting something in each of them.
The variant that we chose is to use the existing js code of the ONLYOFFICE editors. The advantages of this approach are obvious - the development is not so complicated, and the update and the web version, and the desktop are convenient, since the code is the same.
What we wanted :
1. One js / c ++ communication code.
2. Cross-platform GUI.
3. To have the opportunity in the future to switch to the native drawing scheme. The editor code itself remains javascript, but at the same time we should be able to redo the drawing (which is the main brake on the application).
What we have chosen :
1. In order to fulfill the first requirement, we needed a browser engine for all platforms. Since we are very familiar with V8, which, by the way, is used on the server for assembling versions of files, we were originally going to take Chromium in one form or another.
2. Here, too, did not think long. Qt is very common and convenient. Plus, again, there was experience with this library.
3. For now these are only plans. But the point is that js - the editor is spinning separately, implementing all the functionality, and the display, measurement of the text would be native. By the way, this is how we already have a mobile application for iOS.
As long as the native rendering is only in the plans, we needed a conditional cross-platform WebView. We had a few ideas.
Options:
1. Out-of-the-box solutions that we could use, since we still chose Qt, i.e. either QWebView or QWebEngineView .
Of course, if we were to stop at one of them, the main advantages would be that all the main work has already been done for us. It would seem nice, but the disadvantages are still outweighed.
QWebView is no longer developed by developers, it is very, very slow and works in the same process as the application. For us, this was critical, because the designers wanted a “tab-based” interface, which implies opening and working in several documents at once. Thus, if a problem occurred in one document, it would lead to problems in all tabs.
QWebEngineView is a fairly new control, actively developing and based on Chromium. It works in its process and is much faster than QWebView. But he did not fit. First, because of the impossibility of normal operation with native code in the process in which the js code works. Such communication is organized through webkets, which is inconvenient. Secondly, on 4K monitors, for some reason, drawing began to slow down.
2. Pure Chromium . Pros - speed and full functionality. The recently released Visual Studio Code from Microsoft, implemented in just this way, made serious attention to this method.
3. Chromium Embedded Framework . This is a convenient Chromium wrapper, with regularly laid out collected versions (cefbuilds.com). Plus - much easier than the second paragraph. Minus - we lose some of the functionality (many are wrapped and issued as API, but not all).
We rejected the standard approaches immediately, but options 2 and 3 approached us. Of these, we chose a simpler solution, that is, the Chromium Embedded Framework. As a result, cef-based implemented CefWebView, fully satisfying our needs.
Scheme of the application
The resulting application works as follows:
That is: when creating a V8 context, we embed our object, thereby gaining access to the native code from js. Further, if it is necessary to transfer data to another process (for example, to ui), we use the interprocess interaction mechanism built into the cef by sending messages. Similarly, we send messages from other processes to the js process.
And yet, not all eventually implemented as planned. For example, an application under MacOS was made not on Qt, but using XCode.
The fact is that we use QTabWidget for tabs with editors, and under MacOS it is quite slow. This is essentially a simple drag-and-drop of tabs, but in order for everything to work fine, it was necessary to implement this control from scratch. We did not want to do this. Still, we have a little native interface, and it was much more convenient to develop for MacOS using Xcode.
We got what we planned. The application works under all systems and does it with dignity. It is convenient and suitable for those who want to work offline, and at the same time suggests the possibility of connecting portals, which will allow you to use collaborative editing tools and work on documents together with other team members.
For us, this is an interesting new field of activity and more opportunities to do what we love (to constantly improve something). Future plans? A lot of them. First of all, you need to correct the bugs of the editor (JS code), add the necessary functionality (footnotes, table of contents, summary tables, animation, 3D effects). And then - go to the native drawing.
PS You can download the application from our official site . And (almost forgot!) - ONLYOFFICE desktop editors are free for personal use. ONLYOFFICE cloud solution users who have paid for a subscription for 1 or 3 years can get desktop applications for free. For users of the server version of ONLYOFFICE Enterprise Edition - 25 licenses for desktop applications are already included in the subscription price.
Yes, we are the guys who for a long time were engaged exclusively in online editors, and then made offline applications. First, despite the growing popularity of online editors, most users continue to prefer desktops. Secondly, we ourselves have long wanted to get away from the limitations of the browser and speed up the work with editors.
The main feature of our desktop editors in their relationship with online editors - they are united by a common source code. In this article we will explain a little why we decided to make desktops in this way and reveal the secrets of their anatomy, namely - how they differ from the online version, how they are arranged and what we plan to change in the future.
')
What are the advantages of offline editors to online
In this still a bit of the introductory part of the text, we recall that we really love online editors, but not always. Some moments are very sad. Look at the confused face of a user who just tried to copy something from his document, but was faced with an urgent recommendation to use the keyboard? And this poor fellow who just wanted to print, and now downloads pdf? Or is it unfortunate with chopped off the Internet? In general, everyone has already guessed where we are going. Desktop editors have undoubted advantages, and here are the ones:
- The possibility of local work, even in the absence of the Internet (we hope this will never happen to you);
- Use of computer resources. We can realize many things better, many functions work faster.
- Local fonts. Fonts will be taken from the user's computer, that is, if the user adds a new font to his computer, then the next time the editor starts, it will also pick it up. In the case of online editors, the fonts must first be installed on the server.
- The ability to directly send a document to print. In online, the seal of a document is understood as saving it in pdf. After that, the user must take action to send the document to the printer.
- Full use of the clipboard.
- Local spell checker. It's just faster than the online version, in which the word for verification is sent to the spellchecking server.
- Localization of the language. In the desktop version, the language for checking is set automatically, while online you have to choose the language for checking spelling of individual words and paragraphs.
- The ability to go Online-Offline-Online when disconnecting and then connecting the Internet.
So, we were sure that we wanted to make desktops. But we had to answer the question: how?
Methodology
Variant which we refused : native applications. Although we also believe that nothing could be cooler than the native application, force majeure circumstances forced us to abandon this idea due to the complexity and cost of its implementation.
If we chose this option, we would need to rewrite the code of the editors and the entire visualization. In addition, in the future there would be a question of synchronizing updates with the web version of the editors. We would get two codes that do the same thing and would do double work, correcting something in each of them.
The variant that we chose is to use the existing js code of the ONLYOFFICE editors. The advantages of this approach are obvious - the development is not so complicated, and the update and the web version, and the desktop are convenient, since the code is the same.
What we wanted :
1. One js / c ++ communication code.
2. Cross-platform GUI.
3. To have the opportunity in the future to switch to the native drawing scheme. The editor code itself remains javascript, but at the same time we should be able to redo the drawing (which is the main brake on the application).
What we have chosen :
1. In order to fulfill the first requirement, we needed a browser engine for all platforms. Since we are very familiar with V8, which, by the way, is used on the server for assembling versions of files, we were originally going to take Chromium in one form or another.
2. Here, too, did not think long. Qt is very common and convenient. Plus, again, there was experience with this library.
3. For now these are only plans. But the point is that js - the editor is spinning separately, implementing all the functionality, and the display, measurement of the text would be native. By the way, this is how we already have a mobile application for iOS.
Little about drawing
As long as the native rendering is only in the plans, we needed a conditional cross-platform WebView. We had a few ideas.
Options:
1. Out-of-the-box solutions that we could use, since we still chose Qt, i.e. either QWebView or QWebEngineView .
Of course, if we were to stop at one of them, the main advantages would be that all the main work has already been done for us. It would seem nice, but the disadvantages are still outweighed.
QWebView is no longer developed by developers, it is very, very slow and works in the same process as the application. For us, this was critical, because the designers wanted a “tab-based” interface, which implies opening and working in several documents at once. Thus, if a problem occurred in one document, it would lead to problems in all tabs.
QWebEngineView is a fairly new control, actively developing and based on Chromium. It works in its process and is much faster than QWebView. But he did not fit. First, because of the impossibility of normal operation with native code in the process in which the js code works. Such communication is organized through webkets, which is inconvenient. Secondly, on 4K monitors, for some reason, drawing began to slow down.
2. Pure Chromium . Pros - speed and full functionality. The recently released Visual Studio Code from Microsoft, implemented in just this way, made serious attention to this method.
3. Chromium Embedded Framework . This is a convenient Chromium wrapper, with regularly laid out collected versions (cefbuilds.com). Plus - much easier than the second paragraph. Minus - we lose some of the functionality (many are wrapped and issued as API, but not all).
We rejected the standard approaches immediately, but options 2 and 3 approached us. Of these, we chose a simpler solution, that is, the Chromium Embedded Framework. As a result, cef-based implemented CefWebView, fully satisfying our needs.
Scheme of the application
The resulting application works as follows:
That is: when creating a V8 context, we embed our object, thereby gaining access to the native code from js. Further, if it is necessary to transfer data to another process (for example, to ui), we use the interprocess interaction mechanism built into the cef by sending messages. Similarly, we send messages from other processes to the js process.
Xcode for MacOS
And yet, not all eventually implemented as planned. For example, an application under MacOS was made not on Qt, but using XCode.
The fact is that we use QTabWidget for tabs with editors, and under MacOS it is quite slow. This is essentially a simple drag-and-drop of tabs, but in order for everything to work fine, it was necessary to implement this control from scratch. We did not want to do this. Still, we have a little native interface, and it was much more convenient to develop for MacOS using Xcode.
Results
We got what we planned. The application works under all systems and does it with dignity. It is convenient and suitable for those who want to work offline, and at the same time suggests the possibility of connecting portals, which will allow you to use collaborative editing tools and work on documents together with other team members.
For us, this is an interesting new field of activity and more opportunities to do what we love (to constantly improve something). Future plans? A lot of them. First of all, you need to correct the bugs of the editor (JS code), add the necessary functionality (footnotes, table of contents, summary tables, animation, 3D effects). And then - go to the native drawing.
PS You can download the application from our official site . And (almost forgot!) - ONLYOFFICE desktop editors are free for personal use. ONLYOFFICE cloud solution users who have paid for a subscription for 1 or 3 years can get desktop applications for free. For users of the server version of ONLYOFFICE Enterprise Edition - 25 licenses for desktop applications are already included in the subscription price.
Source: https://habr.com/ru/post/279397/
All Articles