unity-design team mailing list archive
Mailing list archive
Re: Unity extensibility. Was: complaints
A better question would be why it cant become more extensible like gnome3 or kde4 ?
why not take advantage of crowdsourcing the features. Hopefully there is a way.
When people first saw Unity they were quite motivated and supposed that it would become the best linux desktop, the one to beat them all, but features come and go constantly. and when people are happy using a feature, Bam! the feature is taken out.
Is like cutting someones arm.
It goes 2 steps forward and then 1 or 2 steps back again.
of course every DE has a rocky start, but all the others are constantly going forward (either by the main devs who focus on the core or by 3rd party contributors.)
Really, removing features is in many ways like removing apps. Is something delicate, because you need to remove only the apps that you know no one needs and not the main one people are using now.
As far as i see it by 12.10 we will be back at unity 1.0 (back in ubuntu 10.10)... :/
We made lots of progress in these years and it seems we are heading back.
There's too much confusion and not a clear roadmap. That's why people are in a defensive mode, because they are afraid of the future and there's a lot of uncertainty. Is a natural reaction.
> Date: Thu, 9 Feb 2012 11:02:38 +0100
> From: mikkel.kamstrup@xxxxxxxxxxxxx
> To: unity-design@xxxxxxxxxxxxxxxxxxx
> Subject: [Unity-design] Unity extensibility. Was: complaints
> On 02/08/2012 10:15 PM, Owas Lone wrote:
> >> Since you are going to Improve this area in the future, I want you to make
> >> control the positioning of any Unity interface element with getElementById
> >> and insertBefore. Later, I want you to add createNode, setAttribute and
> >> removeChild to the API. Then, I would create, update and delete any Unity
> >> interface element. Firefox has this. Can Unity have it too?
> > That wouldn't work. To me the most obvious way to go would be to use
> > GObject system which Unity is built on. lib-peas could provide a nice
> > plugins infrastructure to Unity. With it you could write plugins in
> > almost any language. Exposing a HTML DOM like API for something not
> > built with HTML is just not sane.
> There are several technical problems related to Unity extensibility.
> Firstly we have (depending on how you count) 2 (or more) versions of
> Unity (3d and 2d). Plugins would need to work in all of them.
> "Plugin" to me implies being able to run code inside your host. Unity3d
> currently runs *inside* the window manager process (ie. compiz). Running
> inside a window manager gives certain restrictions, that it takes deep
> understanding, care, and effort to live by. Otherwise you will introduce
> very hard to track bugs and degrade the entire desktop. We can not
> reasonably expect this from plugin authors.
> Unity2d is seprate to the WM, and this is also something we want long
> term for the 3d version, although I aware that there are particular
> plans currently.
> For these reasons (among others) we allow out-of-process extensions to
> Unity. That is quicklists, indicators, and lenses/scopes. Possibly
> others in the future - but admittedly it does limit the amount of
> integration you can do to some degree.
> Related to Firefox extensibility - it is my own experience that it is a
> double edged sword. Sure, you can do stunningly awesome things, but most
> non-trivial extensions will impact general browser performance noticably
> - or introduce hard to track bugs. I've seen this *so* many times. If we
> had something similar in Unity it would not just be the web experience
> that would suffer, but it would be *every* single app and every single
> bit of your desktop that would suffer.
> Mailing list: https://launchpad.net/~unity-design
> Post to : unity-design@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~unity-design
> More help : https://help.launchpad.net/ListHelp