I've just about finished my first MrEd based app for one of my customer's, and I have to say, the experience has been quite positive. I haven't done a whole lot of desktop apps, and so I didn't have a lot go on when I chose MrEd (just some VB, Swing and TclTk experience). It turns out PLT Scheme and MrEd were a good choice.
Here are a few reasons why:
- MrEd produces lightweight, stand alone, executables. This, after all, is the end game and MrEd nails this. The last thing you want to do is write some software and then have to tell your client they need to download a 800Meg runtime library.
- MrEd's GUI framework is simple. Yes, there's a learning curve with respect to the object model, and even with the OO framework that drives it. But compared to say Swing, GUI programming is a breeze. In less than the amount of time it takes to understand how to use GridBagLayout works you can master the entire GUI API.
- It's Scheme, so it's extensible and scalable. With my limited experience with doing GUI programming (for example, a few years ago I worked on a hefty sized swing app - it was called AdMinder, right?), I've found that the layout and GUI code in general can grow to be quite hard to manage. With Java, we resorted to code generation, and just dealing with large files of code. With Scheme, I know I can always write macros which will do the code generation for me. Also, I can take advantage of concepts like mixins that also allow for code generation on the fly.
- There's a real application you can always look at the source of. DrScheme, a feature complete Scheme IDE is written on top of MrEd. This means that you can always grep through some source to see how a particular concept is implemented. It also means that MrEd's framework is grounded in real needs, and not just the hypothetical-we-better-include-it-just-in-case philosophy.
MrEd isn't without some drawbacks. The most significant one is that the GUI isn't easily stylized. You can make some tweaks, like changing the font used in a label, but setting the background color, or getting access to the latest and greatest widget set Windows isn't possible.
For the particular application I worked on, the benefits identified above outweighed the need to have the most customizable GUI. For example, I know that a VB app would have given me access to a pretty looking UI, but the code wouldn't have scaled as well, and who the heck knows how I would do multi-threading or web scraping in a sane way.
I've been looking for the right GUI development tools, so I'll give this a try. Thanks for writing about it, as I hadn't heard of it before.
ReplyDeleteHey Clint -
ReplyDeleteGlad this was helpful.
I should also have mentioned - the PLT Scheme mail list is nice and active. So if you have questions, there's someone to ask them to.
Good luck and let me know when you end up settling on.
The 'lightweight' thing is open to debate :) My one problem with using MrEd for my current project is quailing a little at eventually having to tell my users they need to download an 11MB text editor. I guess it depends on what you're writing, and what the expectation of software size for that class of app is.
ReplyDeleteMartin -
ReplyDeleteI suppose I'm spoiled by broadband and the fact that my past experience was with Swing.
There, you'd be talking about 100's of megs, if not a gig worth of crud.
So, to me, a a 4meg zip file is tiny.
But, you're right, it definitely depends on where you start.
Man, you sure are hard on Java/Swing these days.
ReplyDelete100's of megs? I don't think that's a fair statement. I assume you're counting a JRE install, which is not even close to that size and it's pretty reasonable to assume that most platforms will have a JRE installed.
Java and Swing had there rough spots back in the 'day, but it has gotten a lot better.
Hey Mark -
ReplyDeleteI'm definitely thinking of both Java and .Net experiences where I needed to download big runtimes to get started.
Fairly recently, Shira had to deal with a .Net app, and before she could run it, she needed to download easily half a gig of stuff.
Things do look vastly improved on the Java side, with the JRE weighing in at a mere 14meg.
I think what I'm also mixing up is probably the download of the runtime environment versus the development environment.
Have things gotten better on .jar side too? In my past experience, if you used a variety of 3rd party libraries, the best you could do was jar them all up into one big jar file and make that available.
Does Java offer a cleaner solution now?
If you were to develop an app in Swing, how would you be sure that it looked like a stand alone .exe?
Thanks for keeping me honest about the old versus new world of Java. Someone's gotta ;-).
-Ben
Mark -
ReplyDeleteOut of curiosity, has the Swing toolkit gotten easier in terms of layout managers? Or does one still cut their teeth the GridBagLayout?
Here's one measure of "simplicity" --
ReplyDeleteThere are about 45 methods to digest for a MrEd button.
There are about 405 methods on a JButton.
I'm not saying that the extra 360 methods that Java provides aren't needed. Just that, there's a whole lot more to wrap your head around.
When I programmed in Swing, I was always confident that an effect could be done using the built in facilities. With MrEd, I'm not always so sure - though, usually there's a work around.
But, like I said, for the right project, the simplicity can be huge win.
I really like Python + PyGTK. Glade makes it easy to design the GUI, and one command connects the GUI to your code.
ReplyDeleteIf I had to do a swing gui today I'd use jruby and monkeybars.
ReplyDeleteThanks for the leads guys!
ReplyDelete-Ben
OK, so the full JDK v6 is 66.40 MB. The do offer an "offline" installer that's less than 1/2 MB. Of course, your still going to have to download that stuff, but from a distribution point of view that works well.
ReplyDeleteI really don't worry so much about this "all in one" mentality that you're aiming for in a single .exe. In reality, most real world applications end up being a directory of files anyhow. I mean in most cases you've got to have documentation and other stuff, not just executables. So really, the easiest thing is to just distribute your stuff as a zip file. Apparently building an installer for Java stuff is pretty easy these days, but I've never bothered.
If you really do have just a small application and you want a simple way to package/deploy it, there are some so-called uber-jar capabilities out there. Personally, I usually use Maven for all of my build/package/deploy/dependency management stuff. Maven has a nice plugin called the maven-assembly-plugin, which has an option for jar-with-dependencies. So you put the config in your build file, specify the main class for you application, then all that you need to run it is to run "java -jar myapp.jar". Of course, you can create a nice little invocation wrapper for calling that on unix and for windows platforms. Err, actually, I forgot, you can just double click on a properly built jar file and it will run just like an exe. So there you go.
You can also do something similar with Ant.
Another really nice option, which has gotten better since the old days, and is often forgotten -- remember Java WebStart? Heck, talk about a perfect deployment scenario. You send the customer a link, they click on in in their browser and Voilla! they've got a full blown running application. Ooops, there's a bug in that application, well thank goodness you don't have to ask your customer to re-install the new version of the application with the bug fixes. I think you get the point.
As far as programming complexity, I think things have come along way with Swing. There are some really good GUI builders out there, but I'm still an old fashioned guy when it comes to that. There are some new layout managers, but GridBagLayout, once you get it, is pure power and definitely worth the effort for all but the simplest layouts.
There are also lots of new options for using scripting languages like JRuby, Python, or Groovy to build Swing apps.
And, Mark, that's exactly my point.
ReplyDeleteYou could (and people successfully do!) rig up a JVM + App classes + Jar files + batch script to make a windows install.
But, in the case of MrEd I was impressed that I didn't need to work up a solution like that. Stand alone, reliable executables, were just part of the deal.
Hi,
ReplyDeleteJust saw your post via a link on the PLT-scheme mailing list.
Do you have any opinions on TK or even GNUstep(and relatives)?
cheers,
Stephen
Hey Stephen,
ReplyDeleteI've played with Tk a bit - specifically with Tcl/Tk, but I've never done significant development in it.
I think MrEd shines it two places that Tcl/Tk *may* lack:
1) There's no need to worry about distributing the run time. MrEd will build you a stand alone .exe. Not sure if Tcl/Tk will do this.
2) I wonder how well Tcl scales? I know it's wonderful for quick scripts, but I wonder if PLT Scheme's OO system and Module system, plus Scheme's macros and closures, make for a more scalable solution?
I'm not famaliar with GNUstep.
Now, if you're talking about Scheme (preferrably a mature one, like PLT or SISC) + Tk - well, that's another story. That might be an ideal solution.
-Ben
Tcl/Tk in a starpack: http://www.equi4.com/tclkit/ is about 1mb with full support for virtual file system (won't unpack the files to /temp).
ReplyDeleteCheck it out: http://wiki.tcl.tk
Best language/toolkit/framework I've ever used.
But now I'm tempted to check out PLT Scheme too.
Starpacks require no runtime. Everything bundled in 1mg for several platforms that Tcl supports.
ReplyDelete