diodon-team team mailing list archive

[Dariel Dato-on <oddrationale@xxxxxxxxx>]

I finally had time to do some coding that I promised to do last week. I
updated the bzr branch with a working prototype:

https://code.launchpad.net/~diodon-team/diodon/playground

This can be compiled with

valac --vapidir=. --pkg=gtk+-2.0 --pkg=gee-1.0 --pkg=sqlite3
--pkg=appindicator-0.1  clipboard.vala

using valac 0.8.0 and indicator-application 0.19. I'm not sure how to
specify --vapidir in waf.

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 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.

So I tried Sqlite3 and found it rather easy to pick up. I was wondering why
you would prefer not to use SQL. I would think that your previous experience
in Sqlite would be helpful. I'm not trying to push for sqlite in our app,
but another good thing about sqlite is that it is transactional. So should
(if ever) our app crashes, we know that the data will still be in good
shape. For the code I posted, I used Sqlite since it was easier for me to
learn. We can discuss this more.

If this code looks like a good starting point, then we could consider
cleaning it up, renaming the namespace, and put it in trunk to start working
on. If you have any question about the code, please ask me. It could be that
I am doing things wrong or inefficiently. Here are a few things you might
want to know:

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 is as follows:

[22:47:05] <jury> Odd-rationale: the HashMap simply didn't know how to
calculate a hash value for the keys and how to tell whether they are equal
or not. Because of that, every time you called set/get with a literal
number, it was treated as a different value. By providing a custom hash and
equal functions, you made HashMap capable of working correctly. For some
types (e.g. strings), you don't need to do it and you get a correct
behavior automatically, but not with int64.


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.

Finally, here are some of the things we need to work on:

Localization. Have our app capable of being localized in various languages.
Currently, there are only two strings we need to localize: clear and quit.
We should get the framework in place so it will not be difficult to add
later.

Support for primary/selection clipboard.

Get some settings stored in GConf, such as number if history item, character
length of items, etc. Once we get all the settings in GConf, it will be easy
to add a Preference dialog later.

Be able to execute actions based on the clipboard contents.

Lower priority but need to think about, how will we support files and
images? I don't think we can afford to put a copied file in the database.
Need to look how Klipper manages this.


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!

Anyways, enough from me...

Cordially,
Dariel Dato-on