Is it possible that this extension works with cinnamon? about gnome-shell-extension-appindicator

[genosse-einhorn]

It probably could work with Cinnamon, but I will not implement that and I don't really like the idea of having to maintain it.

This extension does not use XEmbed but a number of more ore less specified DBus interfaces to transmit icons and menus. I might give you a quick rundown how the extension is structured if you'd like to port it to Cinnamon. And maybe one could talk to the Cinnamon devs about integrating the functionality directly into Cinnamon (The GNOME devs rejected the whole AppIndicator/KStatusNotifierItem idea since it didn't fit into their vision of how the desktop should work, but Cinnamon might be different).

[naijim]

Thanks for your reply! I am seriously considering to write a global menu applet for Cinnamon. If you can point out how this works, I will not need to do that from scratch. According to the issue tracker of Cinnamon on Github, the dev team of Cinnamon doesn't like a Global menu either. That leaves me no choice.
So, which DBus interfaces does it use?

[ChurchX]

It's not that cinnamon devs hate & are strongly against global menu, just that is yet another not must have feature to them that it's possible to implement as applet thus is left to 3rd parties to write. At least such has been their standard response in several feature suggestion issues & forum threads. Just like with window grouping on window list - they don't use that, thus closing such issue for stock applet with - "you can write applet to do that".

[genosse-einhorn]

I believe you guys are all confusing AppIndicators and AppMenus. I refered
to indicators since that is what my extension implements. Global AppMenus
also use canonical's dbusmenu protocol, but apart from that they are very
different, both technically and semantically.

[naijim]

If I write an applet that moves the menu bar of normal programs to the top panel of Cinnamon, is that Appindicator or Global Appmenu? Honestly, I can't tell the differences. I guess Appindicator reschedules the strcture of the menu bar but Appmenu not.

[genosse-einhorn]

That would be an AppMenu

[naijim]

OH, bad news. I must write a global Appmenu from scratch...
I think this issue can be closed since an Appmenu and an Appindicator are so different from each other...

[genosse-einhorn]

Well, you could probably reuse most of the Dbusmenu "backend" and some of the "frontend" code, but I'm not sure.

@naijim if you really want to implement the GlobalMenu, I recomend you to see the unity code and the code of indicator. If you can combine, you can have a global menu. See the @rgcjonas words both "use canonical's dbusmenu protocol". He connect the dbus with clutter here, but he do not use the same method to you need, because he want to do another thing, but he use the same thing, the same DBus of canonical. Just to be clear this appear to be a serious work, not just a porting of a thing.
The problem with reuse the code could be the Vala... Cinnamon use python for all things... and this could be a problem. I don't know why Vala it's use to mouch for this days.
It's possible that you need create packages for several distros that use cinnamon, if you want that the applet can work, so before do that, i recomend you talk with cinnamon devs first. They do not want that global menu will be a part of cinnamon default applets, but they can add the necessary packages in the cinnamon dependencies and distribute your code better than you. See that @ChurchX (Cobinja) say.

[naijim]

Thanks for your reply,@lestcape. Actually, I have found a project named Topmenu. Topmenu provides the ability to emulate Mac-style global menu in Mate. I am trying to read the codes. But not too much progress has been made. Since Cinnamon is going to be ported to work with Wayland, Topmenu, which is based on XEmbed, will not be compatible with Wayland. I am searching a XEmbed-like mechanism in Wayland.
link: https://gitorious.org/topmenu

@naijim yes i also search for a project that can be used for this to... And "gnome-shell-extension-appindicator" it's the most close project for do that on internet. Forget the XEmbed, Wayland and all of this things... You need an api with a DBus interface(not relate with GUI), to extract the menu format without involve any other thing, that can be run in any graphical environment(because not depend of the GUI). The presentation of data need to be done by you using the cinnamon api in this case, that it's pretty similar to gnome shell, of course. Then you need to have a hard support (the dbus api) and this is all that you need. Of course that you can use any other project and then make your own Dbus, but canonical does this for you. We can continue the conversation about this in any of my projects in github, or you can open a new project in your account to continues sharing ideas and also i can help you if you want to do that. I have not time to do this project by my self, but i can help.

[naijim]

@lestcape
I am currently running Archlinux. I would like to support Archlinux at the first place,since, you know, I use it everyday. I have no ideas about the differences between Canonical's DBus(it may be patched in Ubuntu?) and the upstream DBus.

@naijim gnome shell can be installed in archlinux and "gnome-shell-extension-appindicator" can run on archlinux too, so... The source of the hard support was take for ubuntu project...
https://aur.archlinux.org/packages/indicator-appmenu/
https://github.com/spo11/archlinux/blob/master/indicator-appmenu/PKGBUILD

The DBus technologies it's a protocol for the apps comunication, between server and clients, you need to define an interface for how the comunication are made... Server and Clients share the interface(to speak the same "language"). DBus technologies is used for message passing only. You can have several application that export the interface for DBus, like for example the canonical interface for indicator-appmenu...

[naijim]

@lestcape
Well, you may be right. I am confused about some concepts of DBus. Let's just leave the concepts for now.
So far I know the global menu might do these jobs: 1) Export the menu bar of the application(I don't know how exactly, maybe with DBusmenu?) 2) Transfer the exported menu bar somehow to the plugin of the Cinnamon's panel(with DBus?) 3) Format the menu bar and display it on the panel(with Cinnamon's API)

@naijim you can not merge inside the cinnamon/gnome-shell panels an non clutter object. So, forgot 1 and 2. You need to have a description(format of the menu) and the actions binding that you can called using DBus, also with DBus you can retrieve the menu format... 3 will be the only solution for cinnamon.

I really don't know how this work, but popup menu can be displayed using the native way, like @rgcjonas said, but you can not insert the principal menu(like mac os) using the native way in the cinnamon panels.

[naijim]

@rgcjonas
Can you give me a "quick rundown how the extension is structured"? I think I am now more or less on the right track. The extension anyhow exports the menu bar and displays it on the panel. So the "backend" can be reused indeed.

[naijim]

@rgcjonas
I have read a tutorial of writing extension for gnome 3. So I can understand part of your codes. I have a quick question for you. How do you control the presence of menu in the top panel? Do you just put the menu bar of program in a structure and deliver it to gnome, and then gnome will handle it? If so, what is the name of that structure?

@naijim this is the rason of indicator, gnome shell don't want to display native things... so he need to generate all menu structure using St... this is not a big problem... gnome shell have a basic structures for popup menu, you can uses and modify this structures like you want. At less in cinnamon you can not have more than one popup menu open at the same time, but this could be changed if you made your own api for popup menu, i made my own api to do that.

[naijim]

How to handle the click events of menu items? I have an idea. It is possible?
I extract the menu bar and transfer it using dbus, a server receives it and handles the graphic stuffs. When user clicks one of the menu items, it triggers an event, the server consumes the event and calls the original event handler of the program.

if you can handle the Dbus this is excelent!!!! Can you upload the work to github?
You can handdle the click event in different ways, depend if you use the cinnamon structure or your own structure. Cinnamon added a virtual click event to some structures, because inside he used another thing and when you conect your app with click event this things that cinnamon made could not be occurs...

The general way:

   _connect: function (actor, event) {
       //connect on release:
       actor.connect('button-release-event', Lang.bind(this, this._onButtonReleaseEvent));
       //connect on press:
        actor.connect('button-press-event', Lang.bind(this, this._onButtonPressEvent));


    _onButtonReleaseEvent: function (actor, event) {
      //do somethings--
    },

actor need to be an St actor(clutter actor)

const St = imports.gi.St;
const Lang = imports.lang;


function ClassName(actor1, actor2) {
   this._init(actor1, actor2);
}


ScrollItemsBox.prototype = {
   _init: function(actor1, actor2) {
      this.actor1 = actor1;
      this.actor2 = actor2;
      this.actor3 = new St.BoxLayout({ vertical: true });
      this.actor3.add(this.actor1);
      this.actor3.add(this.actor2);
   },

   _connect: function () {
      //connect on release:
      this.actor1.connect('button-release-event', Lang.bind(this, this._onButtonReleaseEvent));
      //connect on press:
      this.actor2.connect('button-press-event', Lang.bind(this, this._onButtonPressEvent));
      this.actor3.connect('button-press-event', Lang.bind(this, this._onFatherButtonPressEvent));
   },

   _onButtonReleaseEvent: function (actor, event) {
      //do somethings--
   },

   _onButtonPressEvent: function (actor, event) {
      //do somethings--
   },

   _onFatherButtonPressEvent: function (actor, event) {
      //do somethings--
   },
};

On the last example connect the buttons will be call to this._connect() function

[naijim]

Thanks for your example. I have not written any code yet. Because many details are not clear for me.

@rgcjonas thank for your code to query hard drive temperature via udisks2, it's time to be merge, instead read asynchronous the output of hddtemp program. It's really useful.
Again Thanks.

linuxmint/cinnamon#3032 (comment)