Qt has such an interesting tool as Qt UI Tools , which allows you to reconstruct serialized widgets.

This can be useful, for example, if in a client-server application the server will be responsible not only for the main logic, but also influence the formation of the user interface. For example, because there are modules assembled into a single system, each of which has its own configuration dialogs.

Of course, it will not be difficult to organize your own protocol to describe the settings of these modules, but suppose that this is difficult because the process of changing each of the options in the settings dialog requires the organization of some intermediate data exchange between the server and the client. Because of this, an arbitrary protocol grows strongly due to the various conditions added to it.

In this regard, it would be very convenient if the server module somehow fully described the entire widget (set of widgets), described the data that should be contained in this widget (data generated in runtime ), and finally - the code that should be performed with some user actions on the widget.

The first and second is implemented in an obvious way. Any widget can be serialized on the server side, and reproduced already on the client side. The runtime data of the program, which must be placed in the reconstructed widget, can be transferred separately, and according to some general rules, the client part will bring it into the newly created widget.

But what about, for example, that if a widget contains a button, and for one module this button should do one thing, and another for another? How to transfer the execution logic so that the data exchange protocol between the server and the client does not start to grow under various conditions?

Please share the experience of the implementation of the designated mechanism, and if you used QUiLoader or, perhaps, QFormBuilder , then you passed the actual code / logic of individual widgets. In general, the question arises, why do we need the same QUiLoader , if we pass on the widget the opportunity is there, but what should it do - no?

A possible solution to the problem, I see the use of plugins. Plug-ins could be transferred over the network as files, even QUiLoader not required here. But the accompanying expansion of the application project is very disturbing, since every single plugin is actually a subproject.

  • Oh, this is component-oriented programming ... Such a question, the logic sent by the server, can be anything at all, or can it be originally installed on the client in parts? - AivanF.
  • Some parts of course you can. For example, tables that have standard actions, by the type of addition, modification and deletion of elements. But some actions are completely out of the general scheme, and their presence is essential. The essence of my question is whether there is an opportunity to save so that, anyway, each module is individually signed in the server part, then at the same time you can also cram the UI there and be sure that if you need to make changes later, then all you need is be in one place. - alexis031182
  • I can only plyusanut and also wait for an answer ... By the way, I think it makes sense to specify the platform, because the logic is stored differently everywhere. - AivanF.
  • Thank. Yes, at least just a principle, but if my particular case, then the usual desktop, not mobile devices, with a normal server. - alexis031182
  • one
    @ alexis031182, and how much are you willing to trust the executable code, coming from someone from where and from where to run it with the rights of the current user? Well, in fact - the code can be sent as a normal dynamic library and connect it directly during program execution. Only you need to consider the variety of client operating systems and Qt versions. - ߊߚߤߘ

1 answer 1

But what about, for example, that if a widget contains a button, and for one module this button should do one thing, and another for another?

I would suggest to think in the following direction:

  • Qt - allows us to dynamically build any possible interfaces
  • SQL databases allow us to store in a structural form not only data, but also visual schemes / locations, as well as logic in the form of scripts. I don’t see much point in writing compiled plugins in C ++, because for UI, performance is a secondary criterion
  • Lua - allows, in fact, to implement the logic that is dynamically loaded

A small approximate decomposition of the question

Элемент управления

We already have a limited number of them, for example, QLineEdit, QPushButton, QTableView, etc ... Let's list them in DB in the form of a table and assign them unique IDs so that we can refer to later.

Группы

This is a number of controls that work together. Here we are not talking about visualization, but only that for certain actions, the simultaneous presence of these elements is necessary. Moreover, groups should be able to form not only from controls, but from other groups. Hereinafter, they will probably have to add all the properties of the “controls”. The only difference is in joint independent or dependent work. Let's group and their composition will register in the database.

Роли

These are features of using controls in a group. What exactly, we decide later. For now we will register all roles in the database.

Ограничения

These are statically defined or dynamically generated conditions for the validity of values ​​that may be contained in controls. The limitations themselves, in isolation from the context, are meaningless - they must be tied to roles / roles. But they also need to register in the database.

Состояния

It is a combination of the capabilities or impossibilities of controls to perform actions on the required roles.

Сигналы

These are events that can generate controls depending on the role. On these events, of course, there will be a reaction of neighboring, or overlying controls. Let's register them in the database.

Действия

These are, in fact, software-implemented manipulations with both controls and application data. They "become attached" to signals (which, as I wrote above, become attached to roles themselves). Let's register them in the database.

A small approximate composition of the question

Above are the main entities, manipulating which, you can dynamically collect the necessary business logic for each UI we need. Fortunately, all entities in the database are registered, have unique identifiers. The most difficult thing remains - to register in the database consistent, non-redundant links, which "fit in" with what.

In general, here is the reasoning. I understand that everything is “to the top”, but I am sure that this approach is correct. Another question - is it necessary, is it important?)