2

Allow window to set information about process (session id) and object it exposes.

Shortcuts will be grouped in interfaces and user could select for example invoke media player/pause.

When user invoke action for pause playing above some window, KWin will check session id belongs to given process. If not, nothing happens. But if it is, KWin will invoke method for object, interface selected in shortcuts window and method also selected in shortcuts window.

I known, shortcuts could now invoke DBus event, but user must care about search for info, which event can be invoked via dbus, etc. By preparing standard interfaces, we allow to do many things better. For example - I could turn off gestures support in Firefox and set gestures by my own. Also, we can extend this to not only windows bellow cursor, but also for windows, which register themselves as supporting some interfaces, but this is for future.

I absolutely like the idea, at least what I understood so far ...

Using an interface definition (or template) to be implemented by DBus clients sounds promising. It would offer a clear path towards standard behavior. And more, if would motivate to build an API which exceeds the methods declared in such interface to get aligned to a known and proven terminology. Which might allow for a growing standard ...

It has been a long time since I last looked into DBus, so I have to ask: Is there any "interface support" in DBus?
This appears to be an important corner stone here in my eyes, since DBus is a standard itself that is _not_ controlled but just used by the KDE project.

My English is poor, so sorry...


But. DBUS supports connections (and in this manner session and system bus), names for client (client can register own name on session/system bus or acquire auto generated), objects and ,,,, interfaces.

There is also some DBUS interface, where client can tell what API object support (method to retrieve definition of supporting interfaces in xml format). You could extend last part to help better integrate with DE somehow. Of course, extending this xml application or create own xml application is another approach.

By wrote about shortcut window, I mean KCM (systemsettings5) window. But this idea could be extended for searching each window supporting media playing interface and asks on which object invoke event.

I think the main advantage of such an approach is that it would implement a standard interface to integrate installed applications into the local environment. Not by manual commands or mouse actions, there is little sense in that. But by integration into the existing control elements of the environment. Shortcuts, sure, but based on this approach here I could think of things like an abstract media control framework for example: regardless of what media player you actually install it is automatically integrated into the local environment because it implements said DBus interface.
However the number of potential solutions where such integration makes sense probably is quite small. There are not that many application categories where many alternatives exist that can be considered drop in replacements.

The main reason of the idea was born is for shortcuts. I thought Plasma/GNOME allows to control media player currently....

In other hand, I would say, I created libgreattao many years ago. Currently, I rewrite everything in libxml2 and libxslt.

Libgreattao is tiny abstraction library. Main reason to create libgreattao was to split UI and Business Logic, so UI could be delivered by users or DE/OS vendors. In fact, libgreattao supports stylesheets assembled with templates. You can also invoke app written in libgreattao with special argument to use it with built-in text shell.

Application call for example:
window *win = tao_create_window("/desktop/dialogs/question_dialog")
tao_add_handler(win, "/actions/yes", shutdown, 0)
tao_add_handler(win, "/actions/no", exit, 0)
tao_set_hint(win, "/message", HINT_NAME, "Select, what to do")
tao_set_hint(win, "/message", HINT_DESCRIPTION, "Shutdown the system")
tao_handle_events()

And that's an part of very simple libgreattao app. User can ran it. Libgreattao will ran Gtk+ or Qt gui by default (it will be generated using templates), but user can invoke with special param to ran in terminal shell.
If user do this, he/she could invoke command:
run /desktop/dialogs/question_dialog[1] /actions/yes

And system will shutdown (app must support it).

I think, I could implement possibility to generate dbus API, but without introspection support and many other features.

Hi!

I'm not sure if I understand your idea correctly, but it reminds me of MPRIS.

koffeinfriedhof wrote:Hi!

I'm not sure if I understand your idea correctly, but it reminds me of MPRIS.

Yes.
I said:
"The main reason of the idea was born is for shortcuts. I thought Plasma/GNOME allows to control media player currently...."

MPRIS is also supported by smartphones.

Lachu wrote:I created libgreattao many years ago...

I fail to the see actual connection. This all reads like advertising.
This thread was about DBUS and standardizing entries.

It is similar to Vala feature about exporting method via DBUS. I can add some kind of DBUS backend, since it supports text shell already. But it requires to split some code from my library and integrate it into other libraries, since my library wrapping some parts of GUI libraries, like event loop.

I thought Plasma/GNOME allows to control media player currently...." hellodear.in

teatv apk download

As I said, the main purpose was about shortcuts and system settings 5. Application could create global shortcuts, probably. But what when we had many windows/apps of the same class running?

So we set shortcuts for web browser interface. When we had Elisa, Firefox and Google chrome windows opened and clicked back on mouse, this can be done:
1. Kde reads all actions with back mouse button associated and allow to select previous song, back chrome or Firefox.
2. The same as above, but instead allow of selection, invokes action on window under mouse cursor
3. Both of above, but with prior window under mouse cursor

If there's only one window with this button or action associated and it not under mouse cursor, invokes action on it.

Also, about yours suggestion afkasha. Currently gnome supports apps menu. Kde also integrates window menu into shell. And kde allows to search on menu.