Older blog entries for jluke (starting at number 9)

I've been playing with gstreamer Gtk# bindings thanks to Owen Fraser-Green who delved into the gstreamer source and made the necessary changes to parse it, and fixed everything up for it to be moved to its own module in cvs: gst-sharp. I have now updated platano a simple video player, which was originally writted by Alp Toker to work with it. I need to fix a few small bugs but then it should be working as a good example. Overall most things seem to be working well in the binding.

In case people aren't aware of it Ben wrote a neat little tool called monop that uses reflection to list information about a given type. Very handy when you need quick little bits of info and don't have monodoc runnning. It's my new favorite tool.

It works like this:

monop System.String

The GNOME book is out, and it includes a bunch of samples under the GPL. It might be a good source of information for someone to convert them to C# and put in monodoc. There is a lot of other fun things to do with regards to documentation, so join #mono or post to mono-docs-list and start writing. Most of this can be done right from the comfort of MonoDoc.

One thing that would be great in my opinion is to take small examples, like from the ported GtkDemo, the above book, applications and find places in the API docs that they would fit. It took me less than 30 minutes to do this yesterday for Gtk.TreeSelection, Gtk.DrawingArea, and Pango.Layout. Also, if you find existing examples that no longer compile please let us know (or fix them in monodoc and contribute them).

I think Erik and others have the monkeyguide under control, but I am sure they would like help in some areas if people are interested as well.

Nemerle has a new release, and Pawel Rosanski has been doing a terrific job making it work well with MonoDevelop. Thanks Pawel.

I am pleased to hear of the meeting between some of the GNOME and mozilla guys, although I am not entirely thrilled about anything in the transcript except for the very bottom entry by Marco. He also outlined not long ago ways to improve using Mozilla in GNOME and has been forced to take this on himself it appears. I fully agree with him. Also it appears the GRE has once again been pushed back, to me this is the single most important step in increasing GNOME/Mozilla cooperation. In the end I only hope good things come out of this, which I think they will. My personal advice to mozilla is to focus on the GRE, and write native platform GUIs on top of that, but I don't expect anyone to listen to me.

Although I use Firefox as my browser, I do not think it could be the included browser for distros unless it integrates with native widgets and dialogs better (whether this is a gtk+ or mozilla deficiency I do not know).

In smaller news, the ILAsmBinding should be working with MonoDevelop in svn. Try it out and let me know if something doesn't work, and file bug reports in bugzilla (not your blog). :)

I just finished reading this, which makes me wonder if Red Hat will now remove the GIMP and other programs that use JPEG, like they did for mp3, and why they apparently won't package mono. Things like this really make me angry, especially when they waited so long to make these claims. Apparently their internal discussion on Java/mono/others was moved onto a public mailing list, but I haven't been able to find any archive of it yet.

MonoDevelop can now run java using ikvm instead of a java runtime. I need to allow choosing between javac, and gcj for compiling and a couple other preferences still but here is a screenshot You will need to have setup yourself:

• a wrapper script in your path called ikvm that executes 'mono ikvm.exe args', similar to the mcs one
• run 'mono netexp.exe your.dll' for all the dlls you want to use and put them in /usr/lib or edit the locations to them in your project options classpath
• something else that I likely forgot

Hopefully sometime soon ikvm will be included in red carpet so the manual stuff won't be required, and we can have some way of checking if it's installed and what version it is. I have to say I haven't used Java in a long time, and this little monodevelop + ikvm + mono + Gtk# project was the most fun I've ever had with Java. I wouldn't want to use it instead of Gtk# and C#, however.

I have been reading the Coco/R docs and looking at SharpRefactory tinkering with the idea of porting it to work for Java. I'm not too sure I will ever do this, but it looks interesting at least. I will have to learn all of this grammar terminology before I understand what is really going on.

So i wasted yesterday trying to debug a binding that should be working but just doesn't. The C# code works, the C code works. One function just always returns false. I wish I knew how to use gdb better. Same thing with the vte-binding, it breaks in the managed/unmanaged boundary and I haven't yet figured out how to debug that very well.

Perl is so unreadable if you did not write it. Even when written by very smart people.

Source Editors

It's a tough choice to make, but we are fortunate to have 2 rather good choices with support from both groups (SD and gtksourceview). One thing is that the SourceEditor implementation is different enough from the SD TextEditor that adding the language bindings from SharpDevelop you have to port it instead of just copying it over and it works. Not terribly difficult but an area that being compatible would be nice.

update I fixed vte with two lines of metadata, which makes me feel really stupid. cvs up and try out the sample in gtk-sharp/samples/vte-test.exe

I just finished an initial port of the SharpDevelop Java support to MonoDevelop. So now those who like Java can use MonoDevelop to do simple projects. I have only tested the included projects, so beware on anything else. I did this mostly so I can get an idea of what kind of work it takes to add an additional language. Of course, it turns out to be relatively easy, at least as far as syntax highlighting and project support goes (parsing and code completion is more difficult). Perhaps I'll add a small doc to explain breifly what is required.

Perhaps someone will come along and add a way to directly use mono and IKVM instead of a java runtime and compiler which would be nice, as well as a Java/Gtk# project. (Hint: it probably won't be me)

Edd has posted another well-written and thought out blog over on planet gnome. I just wanted to second what he said and add some thoughts about documentation.

Some of Gtk is documented very well, but you quickly go down hill if you need explanations in a language other than C, or one of the other libraries. Although we have the advantage of looking through others source, documentation is often much easier for people outside the regular group to find what they need.

I think we need to have a way for the api docs on http://developer.gnome.org/ to have examples in multiple (programming) languages and be filtered for the users language of choice. This of course means we need to include bindings for other languages in the gnome releases as officially supported languages.

Hopefully we can convince some of the GNOME supporting companies to employ more resources to documentation, even if it's just some interns or part-time employees. It can be overwhelming for volunteers (I should know because I wrote/ported a lot of the Gtk# docs).

Last, I wanted to mention that this page has been very helpful in learning some of the things about GNOME/GTK that I didn't find anywhere else. I only wish I would have read it _before_ we began porting SharpDevelop to MonoDevelop.

Since the integrated debugger in MonoDevelop is rather dependancy heavy we decided to make it conditionally compile (we will probably do the same for the integrated monodoc). Todd did most of the work and I just finished the Makefiles. So if you are living with a 2.4 kernel w/o NPTL you can compile MonoDevelop again. But the rest of you still get debugging goodness.

Also, today I had to write a small hack for RSS.NET to parse the PubDates for this feed so you can read Paolo's excellent posts on Monologue. Seems like neither mono or .NET support dates in this format:

Fri, 19 Mar 2004 15:13:02 -0700

but it does support:

Fri, 19 Mar 2004 15:13:02 GMT

which is especially strange because I think they are both part of RFC822.

Oh so it works. Work continues at a feverish pace on MonoDevelop. Some better cooperation with SharpDevelop may begin to happen. I guess we are taken more seriously now. Please file more bugs if you are using MonoDevelop.