diodon-team team mailing list archive

[Oliver Sauder <os@xxxxxxxx>]

> First of all, after doing some real coding, I change my minds about
> those coding guidelines we decided on earlier. I agree with you now that
> we should put the brace on a new line. I find it more readable. Maybe we
> can adopt the K&R style braces and indentation
> (http://en.wikipedia.org/wiki/Indent_style#K.26R_style) where we put the
> opening brace on a new line except for control statements? Let me know
> what you think.

I'd still prefer the Horstmann style
<http://en.wikipedia.org/wiki/Indent_style#Horstmann_styleas it is a
neat description without any exception -Opening braces and closing
braces have to be in the same column. However, I can live with the
K.26R_style as well.
Best probably we set up a FAQ on Launchpad about the coding style.

> These are the main things I can think of right now. A plan might be to
> have a release when we reach feature parity with Parcellite. Then we can
> hopefully start getting some users. One of the goals I would like
> to achieve is to eventually be included in Ubuntu by default. I think we
> have the potential of doing that!

I've created a new series 0.1 on lp and added some blueprints with your
suggestions what we have to get implemented. Please feel free to amend
them or mark them as accepted or whatever.
My suggestion about versioning would be to start with version 0.1 with
the end goal of 1.0 when Diodon can be compared with Klipper.

> I looked at some sample code for the libxml2 vala bindings
> (http://live.gnome.org/Vala/XmlSample). It appears that you would have
> to do manual memory management if you are using Xml. I mentioned before
> that I do not have a strong C/C++ background, so that part rather turned
> be off.
> [...]
> I used a HashMap instead of an Arraylist for the Gtk.MenuItem's because
> of the way the sqlite primary keys works. In sqlite, if you have row
> (1,2,3,4) and then delete 3, you are left with (1,2,4). With the
> HashMap, we can keep the hash key and database primary key in sync.
> But when using the HashMap, I had to specify these two
> function: int64_hash_func and int64_equal_func. I'm not exactly sure
> what they do, but it doesn't work without them. The explanation I got
> from the very helpful people in #vala@xxxxxxxxxxxxx
> <mailto:vala@irc.gnome.orgis as follows:
> [...]
> One problem was that the HashMap does not have a index_of() method like
> the ArrayList. So I had to iterate over all the values to get the key.

Here we can see the first limitations of Vala in comparison to Java or
C#. Any C# or Java object implements the hashCode resp. equals method
and therefore this issue is not present. However, as GObject is not a
Vala class but a set of C methods it cannot be enforced that such
methods have to be implemented. A ugly workaround with delegates is
needed ;).

Well but let's talk about the XML versus sql question:
You already brought up some good points why not to use SQL.
One issue you have in sql is: You need a primary key.
You get around this issue with a HashMap but wouldn't it be much more
practical to not care about IDs and just use a List?
Furthermore do I think is xml much easier to extend. Now we just have
one table but in the future more and more will be added. So in SQL you
need relations and such relations need to be presented in vala objects.
Not an easy task.
Furthermore, when the items need to be reordered, in sql a workaround
with a sort id column needs to be implemented. In xml you can easily
reorder the xml tags.
Well, I do see that the vala xml implementations has its flaws, but I
think we can handle them with separating the clipboard implementation
from the data storage.
>From my point of view, our potential data is better representable in
xml. That's just my opinion, but to decide whats best I'm gonna split up
your sample code. I will implement a Software pattern to easily replace
SQL and xml data storage. Also separating the program logic from the
user interface should be our goal so the code will be good maintainable
in the future as well.
I hopefully gonna finish this task end of this week and will have
integrated it into the trunk. This should be a good base to go one
implementing the other features.
In the meanwhile could you try to get some sample code for gconf and
gettext running on Vala? That would be great.

Oh one more thing. I think it would be great to make the application
indicator optional. This would give Diodon the possibility to also get
included in other distribution other than Ubuntu. We might implement
this after we have a first running system.

Oliver