Request of code splitting, for the Applet Cinnamon Menu.

[ghost]

The Menu it's the most development applet, and it's one of most used by the users. The basic function it's more less the same. The diference it's normally the presentation of data. A few days ago, some change in the internar estructure of menu code cause that all break down, because i use another menú applet, wrote by other user, and it's dificult to rewrite in only a few day all code.

Finally i propose that splitting the menu code, and publish in /usr/share/cinnamon/js/ui,
the internal data collection, and only put in the applet the data presentation, to avoid duplicate the code needlessly, when a internal change has be done.

I use this request to say that, the applet's code of Menu have missing some semicolons in the optimizations added recently.
.realize() or .realize();?

Thanks.

[mtwebster]

I spend a lot of time jumping between python, C and js, so apologies for the missing semicolons.

I know some other applets broke that were using settings intended for the included menu applet... They broke when we switched to using the settings api - something they should already have been using, to be honest. I really don't see the gain of fragmenting up the menu applet from what it is now. I would be ok with breaking it up into multiple files, but still staying in applets/menu@cinnamon.org/xxxx.js - probably would be a good idea just for readability - but not putting in js/ui.

[ghost]

I notice the hard work that you have. Not because i see you working. It's because Cinnamon become more and more better. The change in the menu, can notice. The menu reacted more speedy. Much faster. In the Drives Manager that i was developing I had re-writing a code. This change made my Desklet more faster.

I'm thinking that there are already many other popular menus. All of these share a common interface to low level. When a change is needed, all the applet menu need to rewriting. What I propose is in benefit of diversity, it would be nice that the hard part be accessible accessible to all and code rewriting will be unnecessary.

It's clear to me, that you think that the code of Cinnamon use once, should not be in js / ui. But is that good thing of Cinnamon, is the ease with which new artifacts are written and the users (programmers) of Cinnamon sure they would be happy that Cinnamon also provide the hard work. Sure more Menus, with different interface appear.

[ghost]

Not if i can do, but if you can easily import a code of the artifacts Cinnamon and extend them, it would not be necessary to have the code in js / ui and could inherit from them. ¿This can be done easy?

Thanks.

[collinss]

I actually think that it is better the way it is now. Before, every time a change was made to the underlying code for the menu, it broke everything. Now it has been broken (hopefully) for the last time. Now, when a change is made to the Cinnamon menu applet, the other menu applets aren't affected as they all package their own version of the settings. That means future development of the menu will not be hindered by the worry that it will break something, any menu applet released or upgraded from now on will not be bound to certain versions of cinnamon, and also, the settings are now consistent with the rest of the panel.
Also, breaking the code up into multiple files might be nice, but there are so many more valuable things to help make Cinnamon better that I won't hold my breath waiting for that one.

[ghost]

@collinss I understand your point.

When I think in ".js" files without interface, i think that this file are a libraries, and when js "contain" a GUI i think that this files are a programs. So under this scenario, and comparing Windows with Linux, you agree to the Windows and I agree with Linux model.

I mean: You prefer independent installers with code duplication and I prefer share up what you can not (as seems to be the case).

I think that the two the to version of the same thing are also valid. It's only a desition that what can be done.

This is a request, not a bug.
Thanks anyway for show me another perspective.

[ghost]

@collinss also wanted to say that I really enjoyed the audio desket you did. I wanted to make one more simple, that showed the power windows sound like this: http://fc02.deviantart.net/fs18/i/2007/218/7/1/Volume_control_by_Morpheusvista.gif

but you won. Then I would say it would be good if the sound applet can understand your desklet and spend on player control as the user want.

In this case you repeat the same code of Cinnamon Audio Applet, for only change the interface and other more things that you want.

[ghost]

I'm Cinnamon applet, at last...

const LIB_PATH = '/usr/share/cinnamon/applets/menu@cinnamon.org';
// Then add it to the imports search path
imports.searchPath.unshift(LIB_PATH);
const CinnamonMenu = imports.applet;

function MyApplet(orientation, panel_height, instance_id) {
this._init(orientation, panel_height, instance_id);
}

MyApplet.prototype = {
proto: CinnamonMenu.MyApplet.prototype,

_init: function(orientation, panel_height, instance_id) {
    try {      
       CinnamonMenu.MyApplet.prototype._init.call(this, orientation, panel_height, instance_id); 
    }
    catch (e) {
        Main.notify("Error");
        global.logError(e);
    }
}

};

function main(metadata, orientation, panel_height, instance_id) {
let myApplet = new MyApplet(orientation, panel_height, instance_id);
return myApplet;
}