Log in

No account? Create an account

Previous Entry | Next Entry

gtkmm and tomboy

For my own education, I have decided to try porting Tomboy to C++. With regard to C++, I have experience in Qt but not with GTK+. This experiment is designed to accomplish three things:

  1. Test how easily or not my existing C++ skills will apply to gtkmm.
  2. Compare the rate of development with GTK# to GTKMM.
  3. Answer for myself the debate over Tomboy and C# in GNOME.

I DO NOT intend to release this code. I will provide screenshots but nothing more... I do not want to start a flame war or insult the Tomboy developers.

As I progress I will update this entry.

UPDATE: 2006-07-23 19:30 CST

I spent about 3 hours today doing the following:

  • Updated myself with recent changes in libtoolize, autoconf, automake, gettextize, aclocal, pkg-config, etc. GetText posed the most number of quicks. Also messed around with the PKG_CHECK_MODULES macro. In the end I decided not to branch the code based on the availability of gtkmm-2.0 or gtkmm-2.4.
  • Completed porting the Makefiles from tomboy.
  • Got tomboy.cc compiling with gettext support.

Next step is to port the systray. I haven't decided whether to port the panel applet. I need to break for the next 24 hours to work on my Ruby book and stuff for work.

UPDATE: 2006-07-25 23:50 CST

Didn't have time to work on this yesterday. Also, thanks to everyone offering encouragement; not sure how you all found out about this...

I spent about 3 hours today doing the following:

  • Ported Tomboy's own option parser (not really much of a feat).
  • Bludgeoned to death function pointers to get SIGTERM and SIGQUIT trapping working. (It works! Yay!)
  • Abstracted out class definitions to header files.

Next step is, really this time, to get the systray working. Now that option parse is done, it should be pretty easy.

So far, if it hadn't been for the function pointer nightmare with the <csignal> library, I would have been able to say that GTKMM/C++ function/methods are pretty much a one-to-one mapping from GTK#/C#. There is the header nonsense, of course, but once one has the quirks of template, static, const, and function pointers down, there's really not much to it.

UPDATE: 2006-07-29 12:30 CST

I haven't had much time to work on the Tomboy port: I'm packing up all my belongings for the move, GNOME 2.14.3 tarballs are due on Monday and so is the 75% mark for my book's editorial process.

I did spend two hours on it this morning:

  • Investigated murraycu's and hub_'s claims that my sample code about static class method pointers had an unused variable in it. I even broke out the Stroustrup book and cross-referrenced the official initialization syntax to what I'm using. As far as I can tell it's correct. I don't need to initialize it to NULL first, but that was only there because when I tried using the sig_handler variable on the left hand side of an assignment without first initializing it as a static variable, G++ threw an error about using a "variable with an undefined reference" or something like that ... but, Murray was correct that I should have initialized it outside of a static method.
  • Worked on internationalizing the codebase. Mono/C# gets Unicode strings for free, everywhere. To get the same features in gtkmm with Glib::ustring's is nothing short of obscure. In the end, I learned that I should have read the docs on gtkmm internationalization before I started messing around :). So, in order to get a 1-to-1 feature mapping from C# to C++ that is compatible with gettext and can be translated in a sane way, one needs to use this officially referenced library: Compose. Score point 2 for C#. To be fair though, C++ was designed to be compatible with C which, when it was designed, had no concept of UTF-8.

Well that's all for now. Probably won't be another update until some time next week.



( 27 comments — Leave a comment )
Jul. 23rd, 2006 06:00 pm (UTC)
thank you!
Jul. 24th, 2006 09:46 am (UTC)
release it!
please consider releasing it, once it's usable! i don't think you'd offend anyone btw: we're an open community and there are almost more forks than original projects, think about Firefox... Fluxbox... Xorg!

thank you

Jul. 24th, 2006 11:41 am (UTC)
gtkmm and tomboy
I agree with felipe, Tomboy rewritten in gtkmm would be much appreciated and you wouldn’t offend anyone! thank you

Antonio De Luci alias imu
Jul. 24th, 2006 12:52 pm (UTC)
I agree with felipe, Tomboy rewritten in gtkmm would be much appreciated and you wouldn’t offend anyone! thank you
Jul. 24th, 2006 11:38 pm (UTC)
It will not a flame war...
...but a new way for developers. Mono isn't the only way. Thank you for this possibility.

Jul. 26th, 2006 03:17 pm (UTC)
seriously, if you do it, you have to release it. Why? Because it will proves the right or the wrong.

I'll watch your back if you do so. I'll even give feedback. The reason I have never contributed to Tomboy or F-spot is because they are in C#....
Jul. 27th, 2006 03:00 am (UTC)
From a Tomboy contributor
Sounds like a fun project for you. It will be interesting to see how easy/hard it is to translate C#->C++. Personally, I like C# and feel that it enables me to quickly and easily hack on Tomboy, but I understand why people have reservations about Mono.

I wouldn't be surprised if there end up being multiple front-ends to Tomboy, what with the NoteStore abstraction going on for SoC [http://live.gnome.org/Tomboy/NetworkedTomboy]. It would be cool if KDE people had a KDE frontend, Windows folks could have a SWF client if they didn't like GTK, etc. For folks who are opposed to Mono, a C++ implementation may prove useful. I would support you releasing your code, though I'll continue to work on Tomboy in C#.

Hub: I'm not sure what "right" or "wrong" there is to prove. Is anyone saying Tomboy could only ever be done in C#? I guess I don't see why Jason porting Tomboy to C++ is controversial or flamebait.
Jul. 27th, 2006 04:19 am (UTC)
Re: From a Tomboy contributor
I'm sorry, I forgot to leave my name (not a LJ user). I'm Sandy Armstrong.
Jul. 27th, 2006 04:48 am (UTC)
Offending people
No, you are not offending anyone by porting Tomboy to C++ (although I struggle to understand why you'd do that personally).

However people shouldn't take this as a means of killing the Mono debate, the fact that there is a Tomboy++ (let's call it Pantsman to please Jeff Waugh) won't change the fact that Mono is a good framework for a lot of languages including C++, python, boo, Visual Basic and C#. There will still be people like me who will push for it's inclusion in GNOME as that is our poison of choice for GNOME development and it's good for rapid development of good innovative stable applications. Porting one of our killer applications won't change that fact and Mono will continue to help developers push out good applications.

I'd be interested in seeing if there's really all that much to the ressource overhead in using Mono as the rapid anti-mono fraction claims.
Jul. 27th, 2006 07:40 am (UTC)
I dont' know how Tomboy uses the systray (The notification area), but I guess it uses the X API directly. Gtk+ 2.10 (and gtkmm 2.9/2.10) has the new StatusIcon class which might make your life easier:

I don't think your use of csignal (Linux/Unix/Posix? kernal signals) has told you much about "signals" and "signal handlers" with gtkmm. When you start connecting to widget signals, you'll see stuff like this:

C# had the luxury of adding signals to the base language via the delegates system (I think. Correct me, but don't flame me, if I'm wrong), but the libsigc++ way is about good enough.

Do read the rest of that Basics chapter in the gtkmm book.

I have no idea whether a gtkmm app would have more efficient resource usage compared to a Mono app. There's many different things that could influence it, and you wouldn't really be able to answer the question until you'd tried to optimise both the gtkmm application and the mono application. But I'm known to be an optimize-it-later-first-make-it-work guy.
Jul. 27th, 2006 02:53 pm (UTC)
Re: Hints


Thanks for your continued guidance. I appreciate it and am using some of your suggestions.

WRT to optimization, we have a saying in the Ruby community: "Premature optimization is the root of all evil." Which means, generally speaking, you may find that, after you have optimized, you want to through the whole subroutine out the window anyways.

Jul. 27th, 2006 12:08 pm (UTC)
gtkmm and tomboy
I agree with felipe, Tomboy rewritten in gtkmm would be much appreciated and you wouldn’t offend anyone! thank you

Jul. 27th, 2006 01:30 pm (UTC)
Softwaare production process
Hey, is not a rare pattern to code a prototype in a high level language, and then rewrite it in c/c++.
You can write an article later on conventions for converting between C# and C++, and even a semi automatic tool!

Jul. 27th, 2006 02:29 pm (UTC)
I agree with felipe, Tomboy rewritten in gtkmm would be much appreciated and you wouldn’t offend anyone! thank you

Jul. 27th, 2006 03:22 pm (UTC)
Please recompile it PLEASEE
Jul. 27th, 2006 04:10 pm (UTC)
Please release
I don't think Mono/C# are bad things but your work could be useful to the community in ways we cannot foresee.. Please release the code. Thanks.
Jul. 28th, 2006 12:34 am (UTC)
Education rules
Excellent attitude.

I think everyone who participated in the flamewars on d-d-l should reimplement one app in a different language - as punishment, or reward, depending on your point of view. ;-)

Aug. 9th, 2006 06:36 pm (UTC)
C++ !
I agree with felipe, Tomboy rewritten in gtkmm would be much appreciated and you wouldn’t offend anyone! thank you

Aug. 11th, 2006 09:58 am (UTC)
More exposure to Tomboy can't be bad
I absolutely love Tomboy, and have no problem at all running it on my desktop. Then again, I'm a Java programmer, and have for years thought all these "memory hogging, can't perform as good" arguments have been total hogwash.

At the same time, I'd love to see you release a C++ Tomboy. Why? Because one is needed for resource-constrained platforms where the mono runtime is just too big to install. Not too big to run, mind you - just too much stuff on disk. The 770 (Maemo) in particular lacks a good note taking tool and would immensely benefit from being compatible with Tomboy.

Sep. 8th, 2006 03:40 am (UTC)
compose is not the only way
also pay attention to boost::regex
Nov. 21st, 2006 11:01 am (UTC)
C++ tomboy version
Tomboy rewritten in gtk+ or gtkmm would be much appreciated and you wouldn’t offend anyone! thank you

Michele Cremasco
Dec. 18th, 2006 05:19 pm (UTC)
I agree with felipe, Tomboy rewritten in gtkmm would be much appreciated and you wouldn’t offend anyone!

Ciao, Marco M.
Feb. 17th, 2007 01:35 pm (UTC)
Tomboy rewritten in gtkmm would be much appreciated and you wouldn’t offend anyone! thank you

Francesco Frassinelli
Feb. 24th, 2007 11:05 am (UTC)
How's the status of this port
It's been a while since the last update. Just wondering..
May. 16th, 2007 09:19 pm (UTC)
Winnie con patate
I agree with felipe, Tomboy rewritten in gtkmm would be much appreciated and you wouldn’t offend anyone! thank you

May. 18th, 2007 10:03 pm (UTC)
pls release
It would be really cool if you could get around with the tomboy guys and get the stone rolling.

Most of the C#/.Net programs sucks (mainly because of their performance), see banshee, beagle or tomboy as an example.

It would be really cool to push the alternatives to this program instead the .Net versions.

So pls do us a favour and maintain a Tomboy++.

Nov. 20th, 2008 04:58 pm (UTC)
I am agree with felipe
I'm agree with felipe. I don't want C# or .Net in my Linux box...Come on, rewrite Tomboy in gtkmm... it is a great idea, you wouldn't offend anyone!
( 27 comments — Leave a comment )


color, uphair, smile
Jason D. Clinton

Latest Month

September 2011


Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow