libthreepointzero (was: Gnome 3.0)

28. September 2006

Last night, I discussed with Philip about gnome’s api and it’s future.

As you can read in his blogs, there are some problems with wrapping the C API to modern programming languages:

  1. Lists (double-linked and single-linked)
  2. Trees
  3. etc.

For libanjutamm to become a really good wrapper, I would have to copy lots of code from tinymail which is not really a good idea. I was thinking about creating a libtreepointzero which does implement lists, trees and possibly some other stuff in a way that modern programming languages can you it. Philip already wrote most of the stuff for tinymail so the biggest advantage would be that it can be used by other applications.

If there are other people interested in this library, it would be important to have language bindings in a very early stage to be able to change the API in favor of having better language bindings.

This will also give me a nice point to demand a changed gnome 3.0 api.

BTW, Prashanth Mohan, what strange university are you at?

Posted by jhs
Filed in Anjuta, English, Gnome
7 Comments »

7 Responses to “libthreepointzero (was: Gnome 3.0)”

  1. pvanhoof Says:

    28. September 2006 at 16:09

    Hey Johannes. Nice to hear that you are planning to start with such a library. Other people who are actively interested in something like this are Rob and Robert of Collabora. At some point we where discussed things like whether using Vala for this would be a good idea (there where some mixed feelings, but I think the conclusion was that we at least should look at it). the IDL -> GTypeInterface GObject boilerplate code generator which you made for the Anjuta libraries is probably also a very useful tool for this.

    And IDL gives the language binding a standard language for defining interfaces too, that is known by a lot developers and/or not difficult to learn.

    The problem is of course, as usual, our huge todo lists. For me, defocusing from tinymail is not a good idea. I’m, however, willing to help you with this project. By helping you copy things out of tinymail, but also by actively adding new types. I’m interested in helping with both.

    I’m also already imagining myself moving (refactoring) things out of tinymail and starting to use your futuristic library for that. Maybe also talk with Alex, the gnomevfs dude, about his plans for a stream infrastructure.

    I don’t know how the ‘it’ should look yet. But let us openly discuss it. Some of the really good developers in our community (I definitely consider the for example Rob, Robert and you being part of that group) have already talked with me about it. For me that means that we probably should just do it. Or at least start thinking about it more seriously.

    I don’t think we should implement with GObject a full scale class library like what Java and .NET provide. But we sure can make a few nice types that will actually really help a lot developers with making nice libraries that are more easy to make language bindings for in the popular higher programming languages of modern times.

    Modern programming techniques and programming environments like .NET and Java are a fact of life. Let us deal with it like professionals. Or become obsoleted very soon. I know I often use non-soft wordings. Being a consultant myself I get to deal with a lot different types of developers. Trust me that the real world is and will be far less friendly than me for GNOME’s development concepts and platform. Yet we have to deal with it, or be insignificant. Some people have put their passion and life in GNOME. For them, let us not be insignificant.

  2. murrayc Says:

    28. September 2006 at 18:09

    I assume that you are just talking about lists in libanjuatamm. All *mm APIs can already wrap arrays, GLists and GSLists appropriately. Just look at similar stuff in gtkmm.

    The implementation is not particularly pretty, but it works. Even with a higher-level list API, every language binding would still need to do extra stuff to make it more like their language’s own conventions for containers and iterators. For instance, C++ and Java containers and iterators have different syntax.

    However, GtkTextIter is nicer (for C++) than GtkTreeIter, which is nicer than GList.

  3. johannes.schmid Says:

    28. September 2006 at 23:04

    I know that I can wrap a GList with gtkmm stuff but it is just not very pretty.

    The problem was, that GList* is not type safe and I cannot get the correct list type from the idl file with my idl compiler. Phillip pointed out that it would be a good idea to use a higher level API instead of GList* because:

    a) they are “not particularly pretty” to wrap
    b) we can use a special list for a special use-case

    In general this is not specific to libanjuta (we will possible use another solution there) but to a better API in Gnome 3.0! But your opinion as a language binding maintainer is very important here. If you have any ideas how the API could be improved please post them here.

    I am also not sure if I will have the time to work on this library in the next time because I have enough to do for the openimus things and for my exams.

    Johannes

  4. juergbi Says:

    28. September 2006 at 23:06

    I’d definitively be interested in contributing to such a library. As the author of Vala[1] I’d like to perfectly integrate iterators and collections of such a libary into the language as a common base.

    I’d obviously prefer to write the library in Vala and I’m willing to improve Vala in whatever ways it’s necessary to make this as convenient as possible for everyone.

    We should probably discuss a more concrete plan in IRC, don’t hesitate to ping me there.

    [1] http://vala.paldo.org/

  5. murrayc Says:

    29. September 2006 at 11:12

    > The problem was, that GList* is not type safe and I cannot get the correct list type from the idl
    > file with my idl compiler.

    What IDL compiler is this?

    Regarding the item type of the the CList:
    Yes, we must discover this (and it’s often not documented in the C APIs) for each use of CLists so that we can create the type-safe APIs in gtkmm. We also need to discover what ownership the items have – whether we should:
    – delete the list and the items.
    – delete the list but not the items.
    – delete neither the list nor the items.

    However, I guess that this is one of the problems that the new GObject/GTK+ introspection feature has had to solve. So it would be a good idea to find out how they are doing this. The Python guys will know about that, because they plan to use introspection in future.

  6. johannes.schmid Says:

    29. September 2006 at 12:21

    The idl compiler (the C version, I am working on a C++ one) is in Gnome CVS. It’s a perl script.

    We will solve the problem by using List instead of GList* in the idl file to help different language bindings to know the type. In ownership issue needs to be solved somehow of course.

    LibTreePointZero should somehow be able to solve such issues and provide a clean API. I am not sure yet if it would really be useful and how it should do thing though.


Comments are closed.