One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike,
always wear white.
As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
Quick video tutorial (not mine) for using the GTK# GUI RAD:
I started messing with GTK# because I wanted to make a utility for the Mac, and didn't want to have resort to the mess that xibless hacking is for me right now
(http://catchingmono.blogspot.com/search/label/xibless), so I figured I'd look at the GUI RAD for GTK# that comes with Xamarin Studio. I flailed away for a little while, and was able to make most everything I wanted. Then I found the video, above, from 2012, which seems to hold up well. It's really that easy.
With the caveat that I haven't tried to package for anonymous end users, the GTK# GUI RAD is very good. It's occasionally quirky, and has its foibles (wait, if I fill up my layout table with rows, my vbox will pull the statusbar off of the bottom of the window?), but it's very VB6-IDE-esque, which is high praise. Actually, because of the layout managers, it's much better than the pixel-perfect (aka, "Not resizable") UIs VB6 made so easily.
And as an added bonus, if you use the download on this page: http://www.mono-project.com/download/#download-win ... you can run this just as well on Windows as on OS X. And if you grab Xamarin Studio from there, it doesn't look like it downloads all the Android cruft with it like it would from the official Xamarin download page. Here, I *think* you just get the "free" project types. Nice.
I'll attach a simplistic shot, just for fun. Very fast, and I think the worst case is that you tell your would-be utility users that they have to install Mono (or, on Windows, .NET 4.5) and GTK#. I don't think I'd purposefully target Windows-first with this (Visual Studio's GUI RAD is just as good, and is, ultimately, more robust), but I could see making a Mac app in GTK# and releasing Windows and Linux bins just for fun, since they're sitting there.
So my relative dislike of any mergetool that I've tried (list below) has me slowly coding my way to one of my own. I think it's a doable task, now that I've nearly got the [exceptionally simplistic] diff engine close to done. A good mergetool seems to be mostly about the UI, honestly. Can I tell what I'm doing, what's in the current file I'm about to check back in, and the source of each of those edits? Can I tell that I've handled each conflict?
I've got a number of ideas of what's really needed -- saves of past unconflict sessions, quick summations of how much of each file (local, remote, base) you've put into the unconflicted file, the ability to look at the file's history beyond local/remote/base into other branches and farther back in history, etc -- and that's largely GUI driven. I might need a middleware tier for interfacing with git, but that's about it for the faceless code.
The UI, on the other hand, is going to be a bear.
Anyhow, doing this in Mono so that it's crossplatform is both exceptionally cool and horribly painful. Cool in that the faceless C# code really does work great no matter where I run it. Cool in that my code, all written in MonoDevelop on OS X, "just runs" when I opened it in Visual Studio 2010 for fun today. I'm inserting a screenshot, just because it's crazy cool how easily the Mac developed code opens in Microsoft-land.
(Note that it's obviously not close to done yet; still just playing with the diff engine and learning how to do everything in Windows.Forms programmatically -- no RAD designers in MonoDevelop for Windows.Forms. Gtk#, sure. Windows.Forms, no.)
The pain I've documented largely already. You'll notice no highlighting in that screenshot; just colored text. That's b/c highlighting doesn't work on Mono's Windows.Forms for Mac. Nor do ToolStrips. Nor does every menu accelerator. It's a mess.
Just for fun, I'll include a Mac screenshot here... I don't have it handy, so I'll include the one from sourceforge for now. For some bizarre reason, their system added a horrible black border around the image to make it look like it's on an old TV. Go figure.
Which means I'll eventually need to use MonoMac -- a bridge between Mono code and native UIs designed in XCode -- to finish up a quality unconflict for OS X. And since it appears so much of a good mergetool is UI, that means a lot of repeated logic.
Oh well. For now, I'll just use the ugly lowest common denominator of Windows.Forms on OS X, then fork like mad when I get to a good stopping point.
Final thought for now: Writing the diff engine is actually pretty neat. Makes you appreciate what mergetools and diff functions are really doing. You'll notice the "-1" out in front of some lines. That means those lines "didn't change", relatively speaking. That's the wrong way to do a diff. Initially I had way too much of a file-centric approach to diffs, and not diff-centric enough. Working on that. And to do it right, you have to make at least two passes through the code to work out when what's moved has changed order or not.
mergetools I've tried and not really liked:
WinMerge: No three-way merge. Leaves crappy files to clean up. Not updated in a long time, and the rewrite seems dead. p4merge: Great ideas, poor implementation. Love the icons, but I can't always see them. Also hard, with current highlight scheme, to see what I've inserted and what's an option for inserting. No hard confirm on saves. FileMerge: Two-way merge, poorly done, at least when SourceTree calls it. Works fine (aka, "reliable"), I guess, but featureless. vimdiff: Good, but though I love VIm in general, I'm newbie enough to merging files to want to to use a mouse and have more helpful UI cues than just highlighted colors over what amount to tiled xwindows. kdiff3: For some reason, I can't get this to integrate correctly. Using something as a mergetool should be easy. Few are. I don't think this is always saving when and where I think it's saving (same deal with WinMerge and p4merge at times), and often (likely b/c of a flaw in my script, I guess) isn't opening when it's called from cmd line or the git GUI I'm using. Also a little bit of a stodgy interface.
[Mono-bugs] [Bug 75996][Maj] New - menuitem event not triggered by Shortcut
bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com Tue Sep 6 05:52:00 EDT 2005
/sigh I don't think that's been fixed. You know how, when you initially write an app, that you pretty go in and create a good 80% of what it's supposed to look like, it finally all works together, and for at least three minutes you feel like you can rest and call it done? That's where Mono's Windows.Forms support is. It's a great, horrendously impressive beta. Tons of stuff is there, and I can use straight C# to get it all to work, no silly workarounds.
But then, that last 20% is obviously lacking. I can't get SelectionBackColor on RichTextBoxes. There's potentially no working Shortcuts on MenuItems.
And the Mono IRC channels says Windows.Forms is dead. I guess if I was bright enough I could fix it myself, but I don't believe the place I need to fix (some drawing lib) is even written in C#.
I'm really impressed the community got this far, but they didn't quite make the Mozilla turning point before the steam disappeared. It's a "write once, rewrite your GUI everywhere" situation. I guess that's okay, but it makes me wonder how much time to sink into writing the Windows.Forms app before I make sure I understand XCode's Interface Builder.
In other news, Blogger is finally starting to get backwards compatibility right. The old-style BlogThis! bookmark now opens a window that, I think, is starting to get blockquote closer to right (still borked, though), and also expands from its old size to one large enough to see the whole window now. Saves me the trouble of editing the old bookmark's javascript, which I'm embarrassed to say I still haven't. I just resized the window each time I got the new interface.
Although Interface Builder is now integrated into Xcode, itโs still largely the same, with the exception of how Outlets and Actions are now created and wired up. Specifically, it gives you the ability to create an Outlet or an Action and wire it up to a control all in one step.
The postings on this site are [usually] my own and do not necessarily reflect the views of any employer, past or present, or other entity. About Our Author
