What to do with the gobjectification branch

[Jorge Villaseñor]

On Tue, Jan 29, 2013 at 11:39 AM, Sadrul Habib Chowdhury
<imadil at gmail.com>wrote:

> Hi! I haven't done much in pidgin land in the last couple of years,
> but I do have opinions!


Welcome back!


> On Mon, Jan 21, 2013 at 4:14 PM, Richard Laager <rlaager at wiktel.com>
> wrote:
> > On Fri, 2013-01-18 at 23:11 -0800, Mark Doliner wrote:
> >>   - Change one struct at a time (preferably directly in main.  Or, if
> >> it's done in a separate branch, it should be done in a short amount of
> >> time (a few days) and merged into main as soon as possible.)
> >
> > This requires all the struct hiding work to be done. That doesn't appear
> > to be the case on the "default" branch currently.
>
> Perhaps the struct hiding can start with some #ifdef hackery:
>
>     typedef struct _PurpleConversation PurpleConversation;
>
>     #if defined(PURPLE_INTERNAL_STRUCTS)
>     struct _PurpleConversation {
>         ...
>     };
>     #endif
>
> and -DPURPLE_INTERNAL_STRUCTS gets added to the compile commands from
> autofoo.
>
> I seem to remember someone else floated this idea a while back (and I
> almost seem to remember we also started doing this in certain places
> ... but can't find any relevant code)? But this would allow
> incremental struct-hiding in the codebase, without exposing the
> structs to external (third-party) plugins.
>

I don't see why would we need to hide them with #ifdef hackery while we can
just delete them in the development branch (3.0.0)


> I did some work on the struct-hiding and gobjectification at some
> point; and that work is rather tedious. To make progress on these
> areas, the developer needs to be somewhat familiar with the pidgin
> codebase and gobject type subtleties (among other things), and needs
> to enjoy doing things that don't make any visible difference, or offer
> instant gratification. It may be difficult to find someone like this
> (which I think is one of the main reasons for the lack of progress in
> the gobjectification branch) ... unless maybe they are getting paid to
> do this ... summer of code candidate?
>
> Sadrul


I guess you didn't found the code because all that #ifdef were removed when
we moved to 3.0.0 development.

>From my merge attempt from default to gobjectification branch I can say
that most of the merge issues were caused by two different names in the
struct hiding effort (one in gobjectification and the other in default
branch).

I agree it is tedious and it is needed some degree of skills to get it
done. Also, I don't really know how broken it would be to have an hybrid
(some modules gobjectified and some others no) codebase in default (merging
gobjectification to default) and continue the development there. Obviously,
there should be someone who wants to do that merge. =)

My problem now is that we didn't have a clear direction of where we better
point our efforts in the code.

Regards.

-- 
Masca

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130129/a4ebe52f/attachment-0002.html>