Support for multiple instances of the same Applet.

[Lusito]

Separator applet supplied as the most basic sample.
Other uses could be multiple customizable user menus, multiple folder views, etc.
Gschema needs to be recompiled.
Note, that it changes enabled-applets, (adding another ":" separated value to each entry), so going back to a previous version only works if you back up that setting or restore the settings to default.

[dalcde]

A few things (since I have attempted this before as well)

• Do we have to change the "enabled-applets" key in the gsettings schema as well?
  (I see that there is a checkForUpdate thing, but that's not an excuse for not updating or key values :)
• There are some applets that access their own object through AppletManager.applets[]. Will this implementation break such applets?
• The applet_id key seems to increase indefinitely even if users delete their applets. Is there a way to utilize the applet ids more efficiently?
• I haven't read through all your code, but I have also written a system to manage desklets ([1.8] Cinnamon Desklets #1034), that would allow multiple instances of desklets. If you have time (if not, I guess I will do so :), can you compare the approaches and see which is better? I feel that it would be much better if two systems use the same implementation or else applet/desklet coders might get confused about the code format.

[Lusito]

do we have to change the "enabled-applets" key in the gsettings schema as well?
If you are talking about the default value in the gschema.xml, then it doesn't have to be changed, tho for a major revision change, I'd insert default applet-ids.
Currently, it upgrades your settings even if you change the enabled-applets via dconf-editor.

There are some applets that access their own object through AppletManager.applets[]. Will this implementation break such applets?
appletManager.applets does not give you the applet object, but the importer object. This should still work as expected. Tho I am unsure as to where this is actually set.

If you are talking about AppletManager.appletObj, then that would break an applet yes, tho I'm not sure why an applet would do that.
You can easily fix that tho, by using the applet id instead of the uuid to access appletObj. Or by storing the object in a variable as it should have been done anyway.

If you want access to a different applet object via its uuid, that does not work currently, but I guess I could add a function that returns all objects that match a specified uuid.

The applet_id key seems to increase indefinitely even if users delete their applets. Is there a way to utilize the applet ids more efficiently?
Sure, you could check on every insert if an id is already taken, but I don't see the point, since even if you do lots and lots of changes, it most likely won't run out of integer range.
Say you add 20 ids a day for 100 years: 20_365_100 = 730000. Still good in integer range.
If you reuse ids, they are not unique any more. If you have an id that will not get reused, you can use them in an applet to store configurations for that applet safely.
Btw, it should not increase on deleted applets, if it does, that is a bug.

I will take a look at your code.

[dalcde]

Regarding the enabled-applets key, I think it would be more appropriate to change the default value in this pull request.

[Lusito]

Don't pull it just yet, I found an issue I need to check first.

[autarkper]

@Lusito: As far as I can see, this patch apparently interferes with #1253.

[Lusito]

@autarkper: This patch is outdated, check out #1476

[autarkper]

@Lusito : my comment was intended for the new patch, sorry.

[Lusito]

What exactly does interfere ? afaik I had the patch included in my local repository when writing the new patch.
I don't touch the new method in applet.js and the parts in appletManager.js I rewrote a little since I'm storing the actors for the roles instead of just a boolean value.
If it's a merge conflict, it should be ok from what I can see. If the other patch is broken after the merge, then it's a bug that was not intended, probably something really simple, a typo or something..
Maybe you tried to merge in my patch before merging in #1253 ? in that case, it would of course give a merge conflict.

[autarkper]

I just got the impression that minimize-to-window-list-button does not
work with your patch enabled. Hopefully I'm wrong.

[Lusito]

Just tried it, works for me.. did you set traditional minimize effect in cinnamon-settings ?