I was strangely motivated to port some old MonoDevelop code to GtkAction and GtkUIManager today. Something still seems awkward about that API. I'm not sure it is much of an improvement, if any, from the old way of doing menus and toolbars and it seems to make some things slightly harder.

My main beefs are the callback-based adding of the widgets seem to force me to playing with PackStart/PackEnd tricks and that adding non-button ToolItems seems to take an extra step.

I think the second might be able to be "fixed" in a similar way as [Glade.Widget].

Regarding the recent revival of C# v. Java".
I disagree that there are trivial language differences. To put it
another way, cvs and svn are awfully similar from 50,000
feet also. I think if anyone discounts the advantages
of svn over cvs would need their head examined. You might
notice that the Java portion of the article lists several small
stumbling blocks, this adds up when you are dealing with medium
to large applications.

I do hope they actually start using Java instead of Python, however.
I am confident that I will be able to run those programs via
mono (IKVM kicks ass) at some point anyways. Will you ever be able to say the
same for the other way?

I will agree that debating the language can take a definite back seat to
more important reasons that I would favor an ECMA 334 and 335 based environment for
adoption in GNOME.

ISO and ECMA standards

being used in applications today, and ever increasing

language-neutral

runtime (JIT) instead of static compilation

the great people who work on it

This is what the masses of internal IT departments
and 3rd party developers want. As far as
I can tell, these groups are adopting .NET (both C# and VB.NET) in great numbers, in particular through the colleges and universities. I don't think it would be wise to underestimate this effect if you intend to be statistically significant in desktop market or mind share.

Then again, if they don't see the language as very important why do they insist on making it harder for me as
an independent person to do what I want with free software. I'm not going around
telling them they can't use Java or Python. Hopefully, we can go back to moving forward instead of ignoring the issue entirely. It's extremely disconcerting that I even feel compelled to have to argue about this.

Hmm, it seems I have totally forgot to mention I got "Cross-Platform.NET Development" from Apress. It has a wealth of good advice for dealing with .NET, mono, and Portable.NET in a portable fashion. It covers very well the basic differences and probably more importantly the strategy and way to think about portability in the .NET world. Should be of particular use to Windows/.NET projects looking to migrate to more platforms and also Java people (who always seem very concerned with how portable something is) thinking about migrating and wondering if they will lose portability. If this sounds like you I would encourage you to check it out at http://cross-platform.net/.
All this and I have only had time to go half way through it.

I also recently did some more work on monocop, and I think it is ready to be released to the public.

I was always jealous of FxCop, the more automated tools the better I say.
That was one of the things I wanted to get working on MonoDevelop a few
months ago. You see, SharpDevelop wrote this AssemblyAnalyzer thing
that works sort of in the same way. At the time, I hadn't quite finished
the GUI portion of the AddIn so its not enabled in MonoDevelop.

However, I thought why not just slap a little command-line driver in front
of it and then everyone can use it. So that is what I did. Temporarily
called monocop (because AssemblyAnalyzer was too long, and I haven't bothered to think of a real name yet). It can output
either plain text or xml. It should work with make, nant, others fairly well in an automatable way.

It works like this. You specify an assembly or assemblies to analyze, and
it will warn you of possible design and naming problems. It also supports
custom rules and looks to be fairly easy to add more. It only has about 87
rules right now.

Some example output:
$ monocop -xml -output:results.xml hello.exe

<?xml version="1.0" encoding="utf-8"?>
<Assembly Path="hello.exe">
<Resolution Certainty="95" Priority="Error">
<Item>/home/jluke/hello.exe</Item>
<Description>Assemblies should be strong named</Description>
<Details>Assemblies with a strong name can be placed in the GAC. Furthermore only strong named assemblies can be referenced by a strong named assembly (Your assembly cannot be used by a strong named assembly if you do not sign it).</Details>
<Text>Sign the assembly hello.exe with a strong name.</Text>
</Resolution>
....

Florida lost to Mississipi State, hopefully this will end the Ron Zook fiasco
at Florida. When someone is demoted to Special Teams coach 10 years ago, how
can you expect him to be a successful head coach. I know I didn't.

Things an application may need to do during installation:

Add a menu entry

Register mime-types it handles

configuration data

add documentation to monodoc/yelp/others

various others I missed (i18N)

For example, MonoDevelop needs to add a few mime types and occasionally syntax definition to gtksourceview to work fully. It works
without installing (unpack it and type make run), but just enough is missing
to potentially make things harder on you.

For some reason GNOME and others seem to increasing the dependence on
$prefix and path specific files for the above things. You put a .desktop
file here, an app.xml file there and run update-mime-database /some/path/,
put a gconf schema here and do something else. Then if PATH, LD_LIBRARY_PATH,
PKG_CONFIG_PATH aren't set right or you don't have root permission it
doesn't quite work.

It really seems like there should be a better way. Here are some options:

I used to think we would be lucky if we could get to the point where
autopackage was widely accepted in addition to rpm/deb. Now I am
hoping for more. In particular, bundles seem rather appealing without
me having had the chance to play with the Mac and discover its shortcomings. It certainly seems doable to me.

I wrote a C# implementation of the freedesktop.org Recent Files spec today that seems to work ok with existing gnome programs. It is not very well tested, so be careful. For those interested it is here, http://bugzilla.ximian.com/show_bug.cgi?id=54880
even though it is not MonoDevelop specific. You want just the RecentFiles.cs file if you want to try it, please dont add comments to the bug unless it is about MonoDevelop. Specific things about RecentFiles.cs can come straight to me, including where it should eventually live if people find it useful.

Seems to be good news on what me and Todd talked about the other day. Doesn't seem to mention the other bills though. Link is to slashdot because of those stupid newspaper registration things. Draft bill shot down You can probably find a better link through google though.

I watched the VP debate which was lackluster at best, still wish each party didn't conflict with themselves so much. I guess it is much easier to find faults, than fix them.

Laszlo sounds interesting without me really reading anything about it, sort of Flash MX-ish but now open source. If it only didn't require the hopelessly complicated J2EE. Looks like they plan to integrate with Eclipse (only speculation on my part because they chose the same license).

I messed with some more bite-sized mcs stuff today, small error fixes and stuff. Most of the test failures now seem to be where mcs reports a generic parser error, instead of a more specific one, which would be nice to fix but probably not a high priority. I think I am getting to the point that I understand (most) of the process now, but not enough to write a compiler yet.

Todd, I cant get to the first link, so I will assume it is to the Charles Rangel bill. The other bill is by Fritz Hollings (a RIAA/MPAA favorite). Since the two Senators who have written these bills are democrats, who are you advocating voting for?
I was sure you were against Bush (who does not plan on reinstituting a draft). As far as I can tell neither bill has much of a chance of passing, but who knows.

I just spent 10 minutes writing a tool to generate a Makefile for a directory of .cs files, I have to wonder why I didn't do so a very long time ago.

Updated:
I didn't assume anything and I am not naive. Just mentioning a related fact in case anyone believes the conspiracy theories going around that Bush and/or Republicans are secretly planning what Democrats are doing in plain sight. In any case, (most) politicians are members of a party in which they both have influence and are influenced by, so it is related to the presidential vote.

Since Todd
enumerated why you should vote for Bush, I thought it only fair I do the same for Kerry.

Top 22 Reasons to vote for John Kerry

1.

Since it seems to have been deemed appropriate that we all become sideline political commmentators lately. I would like to point out it is not only important that you do vote, but that you think before you vote. You can spend 20 minutes finding out about where each candidate _claims_ he stands on all the issues instead of just one. I can almost guarantee you will find some surprises while doing so.

In more on topic news, I have become distracted with a new (mono-related) project that I should have never started in the first place. That whole reinventing the wheel thing that people hate so much, but I seem to enjoy doing. Anyways, "hello world" worked for the first time yesterday so hopefully it will be ready for public announcement in a couple weeks. Real world utility is probably not very high, but it has certainly been educational.