> The Mint guys seem smart, so if they feel that a fork is necessary then it's probably the only way to do what they want given the constraints. These are the

> The Mint guys seem smart, so if they feel that a fork is necessary then it's probably the only way to do what they want given the constraints. These are the constraints for him, as far as I know (looking at the gnome-shell code): 1) extensions can't modify the original layout of the shell, because they are loaded after the shell elements are created. You can monkey-patch the shell, but only so much. 2) There is no easy way of destroying the panel (or other ui objects). 1) happens to be true because of the extensions constraint that they should have the ability to be turned on/off. That means that their entry point in the shell gets to be after the main ui objects are created. You can add new behaviors to them, and override them, except for their initialization (obviously). The extensions system doesn't expose an API that allows for multiple entry points (for example, having extensions derive from an Extension class with Base and Restartless subclasses). This might be a design oversight, but for the most part it is sane, since it creates a base of code one can expect to be there, that any extension could depend on (again, simplifying inter-extension compatibility). Extensions written for gnome-shell won't be compatible with extensions written for cinnamon, which is extremely bad in my opinion. It means the developer community that's been growing around the platform might break into multiple directions, which can hurt users. If there was a way of destroying the panel (or other main ui objects), though, there would be no need at all for this fork.