[...] > But it seems a pity to have to duplicate the glib interface for each >> structure that offers the facility, can we just return the GData and let >> the plugins use the normal g_datalist functions? >> >> [...] >
To summarise the answer to the question Matthew gave on IRC, no, we don't have to duplicate the glib interface but it makes it easier to clean up after plugins if we do. And its unlikely that many other structs will need it. Ok, if thats the case then its reasonable to duplicate the (fairly small) g_datalist interface for the few structs that need the functionality. [...] > We could just use the usual idiom (in G*) and use objects that have > destruction signals and reference counting and such stuff that is useful > for this type of scenario. IMO it'd be more useful to just treat > GeanyDocuments like other stuff, and maybe having an _is_open() or > _is_closed() function or something to see if the document you have a > reference on is still open (if you didn't want to connect to its open/close > signals it could emit). No problem to replace is_valid with an is_open function that can hide the implementation. But whichever implementation is used, it is going to have to be able to identify if a pointer is no longer to an open document. The current implementation sort of does that by keeping the document objects around so the test of the boolean is_valid is always legal. Comparing the pointer against the list of open documents is a (slower) alternative. It could also be implemented in some other way. Cheers Lex > > Cheers, > Matthew Brush > > ______________________________**_________________ > Devel mailing list > Devel@lists.geany.org > https://lists.geany.org/cgi-**bin/mailman/listinfo/devel<https://lists.geany.org/cgi-bin/mailman/listinfo/devel> >
_______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel