GNOME Bugzilla – Bug 605172
rewrite the current interfaces in Vala
Last modified: 2010-06-07 20:56:23 UTC
The patches are based on 8eb161319bbbb953271631da04dd7611a4f97009 which is relatively old, but nevertheless, I'd like them to be reviewed before I go further. for example, I'm requiring automake 1.11, should I rewrite to use a lower version? (anjuta now requires 1.9) There is still a problem with IAnjutaDebuggerInstructionDisassembly. The patches follow
Created attachment 150197 [details] [review] fix enums in gbf-project (they were not picked by glib-mkenums)
Created attachment 150198 [details] [review] plugins: include libanjuta-interfaces.h instead of individual headers
Created attachment 150199 [details] [review] libanjuta: include libanjuta-interfaces.h instead of individual headers
Created attachment 150200 [details] [review] plugins: do not rely on IAnjutaBuilderHandle and IAnjutaLanguageId typedefs (since Vala doesn't handle typedefs well, these will be removed)
Created attachment 150201 [details] [review] interfaces: use Vala instead of anjuta-idl-compiler.pl also add support for building gobject-introspection files
Created attachment 150202 [details] [review] remove virtual signal handlers from interfaces
Review of attachment 150198 [details] [review]: I am not in favour of this change, or the similar following patches. It's is crucial to keep the interfaces independent since these are heavily used by plugins. Otherwise, it will require rebuilding everything in anjuta and plugins for unrelated changes.
Yes, I'm aware of this problem. I've discussed this with Johannes Schmid, but haven't updated this bug. btw, I've created a repo on github [1] since it's easier to merge big changes than rebase them. I'll post here and on the mailling list when they are ready for merge. btw, Johannes said it's ok to have related interfaces grouped in the same header, are you ok with this? [1] http://github.com/abderrahim/anjuta
While I am fund of replacing our crappy idl compiler which something we don't have to maintain ourselves, I am not sure if Vala is currently in a state to replace it. What I would like to concentrate on instead is to make gobject-introspection working on libanjuta so that it becomes easier for language-bindings to use it. (At least for those which use introspection).
(In reply to comment #8) > > btw, Johannes said it's ok to have related interfaces grouped in the same > header, are you ok with this? > > [1] http://github.com/abderrahim/anjuta Very closely related interfaces should be fine to group. But I wonder how well it goes with 1 gobject-per-file style with glib/gtk+/gnome. Vala after all generates gobject files in the end. Anyways, if vala is fixed to generate it correctly, this would be the least of our concerns.
(In reply to comment #10) > (In reply to comment #8) > > > > btw, Johannes said it's ok to have related interfaces grouped in the same > > header, are you ok with this? > > > > [1] http://github.com/abderrahim/anjuta > > Very closely related interfaces should be fine to group. But I wonder how well > it goes with 1 gobject-per-file style with glib/gtk+/gnome. Vala after all > generates gobject files in the end. Anyways, if vala is fixed to generate it > correctly, this would be the least of our concerns. But it's not okay to separate the vala file into small files in an attempt to generate separate files (if that's the only way out left). That will kill the convenience of updating libanjuta interfaces in one place like we do now. Vala should be instead fixed to provide a compiler option to generate 1-gobject-per-file.
(In reply to comment #9) > While I am fund of replacing our crappy idl compiler which something we don't > have to maintain ourselves, I am not sure if Vala is currently in a state to > replace it. > Vala is certainly an interesting substitute for our idl compiler. I think if we can communicate our needs to vala upstream, it could be a good choice later when it's ready for us. > What I would like to concentrate on instead is to make gobject-introspection > working on libanjuta so that it becomes easier for language-bindings to use it. > (At least for those which use introspection). I fully agree. We need the bindings to work first. They are so important to get plugins development moving.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #8) > > > > > > btw, Johannes said it's ok to have related interfaces grouped in the same > > > header, are you ok with this? > > > > > > [1] http://github.com/abderrahim/anjuta > > > > Very closely related interfaces should be fine to group. But I wonder how well > > it goes with 1 gobject-per-file style with glib/gtk+/gnome. Vala after all > > generates gobject files in the end. Anyways, if vala is fixed to generate it > > correctly, this would be the least of our concerns. The problem is that you and vala maintainers don't have the same idea of what gobject-style mean. For vala, this means as much source files as wanted, and only one header (for use like #include <gtk/gtk.h>). > > But it's not okay to separate the vala file into small files in an attempt to > generate separate files (if that's the only way out left). That will kill the > convenience of updating libanjuta interfaces in one place like we do now. Vala > should be instead fixed to provide a compiler option to generate > 1-gobject-per-file. IMHO, (and that's what I understood from Johannes, maybe I've misunderstood) having one huge file is a limitation of the current idl compiler rather than a feature. If you want to keep only one file, I beleive Vala is not going to help : Vala is a general purpose language, not some kind of idl compiler. Even the old 0.6 branch won't generate a header file per gobject if they aren't in different source files. The advantages I see for Vala, though, are gobject-introspection gir files generation with correct memory management without needing gtk-doc annotations, and the ability to remove unneeded "GError **err" parameters. Anyway, since there doesn't seem to be a consensus about this, I'll try to separate changes for gobject-introspection, and leave the rest for a later time.
Personally, I don't want to have one generated file containing all interfaces definitions, as it will need a complete recompilation of Anjuta each time an interface is changed. But, I don't see a problem if libanjuta.idl is split in several vala files. A few interfaces already need some related objects defined in several C files. Anyway, if you can separate the two parts it will be perfect :)
(In reply to comment #13) > > The problem is that you and vala maintainers don't have the same idea of what > gobject-style mean. For vala, this means as much source files as wanted, and > only one header (for use like #include <gtk/gtk.h>). That seems like limited idea to me, and I don't think that's really one of ideas of vala, but rather just a limitation in the way we define our stuffs. I had the opportunity to talk to Jürg Billeter in fosdem about this matter. According to him, I got the impression that the problem is mainly that (a) nobody probably needed it yet, (b) it was a complex thing to sort out inter-dependencies of the header/object files. I asked him to see a possible solution for this, perhaps as a compiler option or something. We should perhaps followup the discussion with vala team in their ML to continue this. Whether it is possible or not is currently open. > > > > But it's not okay to separate the vala file into small files in an attempt to > > generate separate files (if that's the only way out left). That will kill the > > convenience of updating libanjuta interfaces in one place like we do now. Vala > > should be instead fixed to provide a compiler option to generate > > 1-gobject-per-file. > IMHO, (and that's what I understood from Johannes, maybe I've misunderstood) > having one huge file is a limitation of the current idl compiler rather than a > feature. If you want to keep only one file, I believe Vala is not going to help A huge file is may be not ideal, and I am not particularly against splitting into reasonable sized chunks of files, especially with related interfaces together, and independent interfaces separate. However, splitting every individual interface into a separate file will result in huge number of tiny files to maintain separately, each perhaps only containing a few lines. Instead of either-or, we try to get something in the middle that works well. Can you try to proposing grouping of the interfaces? Perhaps we can understand better if it helps come around this limitation. > > Anyway, since there doesn't seem to be a consensus about this, I'll try to > separate changes for gobject-introspection, and leave the rest for a later > time. That's good. I would indeed want to have them deat separately. If I haven't mistaken, gobject-introsection compatibility has probably nothing to do with vala-fication. I see vala for IDL as a way to improve our IDL generation, while introspection part is very crucial for bindings generation.
Review of attachment 150197 [details] [review]: Thanks, this patch is generally useful!
Closing this bug! We should focus on making the whole API introspectable!