Vincent Untz Goes Over The Direction Of GNOME

[Vim_User]

API on extensions? WTF!? Extensions alter existing gs code, there is no API.

Funny, Gnome developers see that differently:

but we didn’t want to change the extension API

That was the only API break that I inserted into the extension system for 3.2

While I hate to break API, I’d say it’s for the better.

We now have a usable API for settings from extensions.

http://blog.mecheye.net/2012/02/more...on-api-breaks/

So this developer is clearly speaking of an API (and breaking it) that you claim doesn't even exist. Maybe you don't know as much about Gnome as you think?

[kigurai]

Funny, Gnome developers see that differently: http://blog.mecheye.net/2012/02/more...on-api-breaks/

So this developer is clearly speaking of an API (and breaking it) that you claim doesn't even exist. Maybe you don't know as much about Gnome as you think?

If you actually read more than the title, you would realize that this "API" is the same type of API that you have with Linux kernel modules. It defines extension loading/unloading and preference handling, but not how to access the functionality of the host.
AFAICT extensions still have unlimited access to the Shell, without any kind of "extension API".

[funkSTAR]

If you actually read more than the title, you would realize that this "API" is the same type of API that you have with Linux kernel modules. It defines extension loading/unloading and preference handling, but not how to access the functionality of the host.
AFAICT extensions still have unlimited access to the Shell, without any kind of "extension API".

True. Unless of course mr vim kan provide us with a link to a well defined and documented API.. Show us your super powers vim.

[Vim_User]

If you actually read more than the title, you would realize that this "API" is the same type of API that you have with Linux kernel modules. It defines extension loading/unloading and preference handling, but not how to access the functionality of the host.

So now it is important which functionality is made accessible through an API when we want to determine if it even is an API?

True. Unless of course mr vim kan provide us with a link to a well defined and documented API.. Show us your super powers vim.

I have shown you a link to a blog post from a Gnome developer describing that what he calls "the extension API" and where he decribes that they will break it if they want to. No superpowers needed, I have backed up my claims, time for you to do the same.

[kigurai]

So now it is important which functionality is made accessible through an API when we want to determine if it even is an API?

Well, of course it is an API, no one is contesting that.
But I think you could argue that not all API are alike.
On the one hand you have APIs like, say GTK+ or Qt, which are rigidly defined and guaranteed to not break between versions.
Then you have stuff like the Linux kernel where you of course have an API, but it is not guaranteed to be stable between even minor version numbers.
GNOME-shell extensions fall in the latter category.

I have shown you a link to a blog post from a Gnome developer describing that what he calls "the extension API" and where he decribes that they will break it if they want to. No superpowers needed, I have backed up my claims, time for you to do the same.

The API that broke in this case was that the mechanism for loading the extensions was changed. There is still no stable API for Gnome-Shell.

I am not sure why the lack of a stable API is anything to be upset about though. The kernel has the same policy, and everyone seems to agree that this is a good thing.
I think the same reasoning is applicable in this case.

[Vim_User]

I am not sure why the lack of a stable API is anything to be upset about though. The kernel has the same policy, and everyone seems to agree that this is a good thing.
I think the same reasoning is applicable in this case.

The kernel has the very important rule: We don't break userland. Userland is what makes the kernel into an OS. Pretty similar like many people claim that extensions are the one thing that make Gnome Shell usable for them. So you can see extensions in a way as Gnome userland, but Gnome developers (and GTK developers also, just ask some developers that use GTK putside of Gnome, or even people designing GTK themes) have no problem with breaking userland, regularly. They just don't care and some people even think that this is intentional, since anything not Gnome will not be accepted, in fear of damaging the Gnome brand.
Some people also think that the current effort of using extensions to get a classic mode is not because the Gnome developers finally hear what their users want, but to bring the extensions that are used anyways by Gnome users under control of the Gnome brand, to eliminate non-Gnome things on Gnome.

If that is really the case, I can't say, but when you see some statements of Gnome developers and their behavior one could think that this is not so far from the truth, that to them the brand is more worth than the userbase.

[kigurai]

The kernel has the very important rule: We don't break userland.
Userland is what makes the kernel into an OS. Pretty similar like many people claim that extensions are the one thing that make Gnome Shell usable for them. So you can see extensions in a way as Gnome userland, but Gnome developers (and GTK developers also, just ask some developers that use GTK putside of Gnome, or even people designing GTK themes) have no problem with breaking userland, regularly. They just don't care and some people even think that this is intentional, since anything not Gnome will not be accepted, in fear of damaging the Gnome brand.
Some people also think that the current effort of using extensions to get a classic mode is not because the Gnome developers finally hear what their users want, but to bring the extensions that are used anyways by Gnome users under control of the Gnome brand, to eliminate non-Gnome things on Gnome.

I specifically mentioned kernel modules, and said nothing of userland.
I think extensions should be considered the same as kernel modules in this case, since they are tightly coupled to Gnome-Shell and modify its core behaviour.

Whether GTK+ has broken API or not is irrelevant for this discussion.