Re: [gedit-list] libgedit, again

[Sébastien Wilmet <swilmet gnome org>]

On Sun, May 03, 2015 at 09:08:24PM +0200, Sébastien Wilmet wrote:
> Yeah, creating the gcode directory in the gedit repo is quite a big
> change for the code organization.

I've continued the gcode proof-of-concept, and I think it could work
quite well. But the branch needs to be re-done, because gcode/ needs to
be inside the gedit/ directory, to have one public gcode header that
contains some class definitions used for public gedit classes. For
example GeditDocument needs to be a subclass of GcodeDocument, but since
GeditDocument is a public class, we need the definition of the
GcodeDocument and GcodeDocumentClass structs. So we would have an
#include like this:

#include <gedit/gcode/gcode-gedit.h>

So that's why gcode/ needs to be inside gedit/ (so that that #include
works when compiling the gedit code, and it also works when compiling
plugins out-of-tree, if gcode-gedit.h is installed).

So since the gcode branch anyway needs to be redone, it's probably
better to move to gcode when there will be more interesting stuff than
just gedit-utils, gedit-metadata-manager and gedit-document. Some
gedit-document functions could also be moved to GtkSourceBuffer or
GtkSourceFile (but it's more work, to be sure that the API is nice).

So I'll redo the gcode POC when more code in gedit is ready to be made
reusable. This includes GeditTab and all it contains. I can do
refactorings in that code, create a debug utility, deprecate the useless
utils functions, maybe create a subclass of GtkSourceFile if it's
useful, ditto for the FileLoader and the FileSaver. Try to shrink the
code of GeditTab, etc. And of course fixing some bugs along the road.

So for gcode, what doesn't work well is the documentation. Ideally I
prefer having gcode well documented, with its own GTK-Doc generated
documentation. But for public classes in gedit, the documentation would
need to be duplicated. In gedit we could write the doc "see
gcode_blah()". Or in gcode we could write "see gedit_blah()". I tend to
prefer the latter, since plugin authors cannot use gcode (it's
completely internal to gedit). But for the documentation of properties
and signals that are implemented in gcode, it's more complicated to
document those for gedit. So, I don't really know. That's the ugly part
of gcode.

Another ugly part is all the delegate functions for public gedit
classes. For functions taking a variable number of paramaters, new
functions that take a va_list argument must be created in gcode (there
is no other solution in C, except creating ourself a GSList for
example, but va_list is simpler and more standard for such cases).

Do you have other comments about the gcode branch? Do you see other
problems? Or could it be merged like that if the history was cleaner?
provided that the re-usable code is useful and contains interesting
features.

Note that currently in the branch, gedit-document is not completely
done. But I think with the gcode-gedit.h public header it's entirely
feasible. Maybe with some tricks for the documentation.

--
Seb