Re-namespacing Pidgin's API for Introspection

[Peter Lawler]

On 08/02/14 08:11, Jorge Villaseñor wrote:
> On Fri, Feb 7, 2014 at 2:18 PM, Ankit Vani <a at nevitus.org> wrote:
>
>>> I am not sure I have understood the issue but AFAIK we have different
>>> namespaces
>>> * Pidgin
>>> * Purple
>>> * Gnt
>>> * Finch
>>> each of them refering to the specific component.
>>>
>>> The Gtk namespace is used most of the times when we write a gtkwidget
>> which
>>> is not shipped by Gtk+ so we maintain it locally (gtkimhtml, as example)
>>>
>>> The problem is to have this Gtk and Pidgin namespace together? I don't
>> think
>>> they should be merged since one is referring to gtk widgets and the other
>>> one is Pidgin's API.
>>
>> The way introspection expects it is that everything from libpurple goes
>> into the Purple namespace, everything from libgnt into Gnt, pidgin into
>> Pidgin and finch into Finch (which I also personally believe is the right
>> way), without defining things in the Gtk or Glib namespaces. This would
>> allow, for instance, a python plugin to do
>> 'from gi.repository import Pidgin' and use Pidgin.Whatever stuff.
>>
>> The distinction you are suggesting can be handled by something like
>> PidginGtkWebView instead of GtkWebView, if really needed. Still,
>> PidginWebView still sounds cleaner. The generated gtk-doc docs will show a
>> type heirarchy for GObjects, widgets etc.
>>
>
> Mmm I ask old developers, this gtk_* widget were supposed to be sent to
> Gtk+ to be integrated upstream? I always thought that was the idea, we
> maintain them in the meantime they accept the widgets, if they were not
> merged we keep maintaining them.
>
> Is this somehow true? If the plan is to always maintain this widgets as
> part of Pidgin, I will +1 to change the naming to Pidgin specific.

ok, I'm awake now! (mostly)

iirc, it was for basically for stuff that can't be guaranteed to be in 
'all' common distros out there at the moment. eg, 'enterprise' linuxes 
that have longer support life than typical 'bleeding edge' GTK life 
cycle, as well as for new stuff that hasn't made it in to distros of a 
not ancient but not brand new age either (eg, 1 year old)

It's sort of the reason why some commercial Linux applications can be so 
massive compared to Win*/Mac versions. To guarantee certain versions of 
certain widget stuff is available (and in the case of 'new' features 
that are in flux, provide some API stability that otherwise wouldn't be 
available)

HTH,

Pete.