|
title: Put the knife down and take a green herb, dude. |
descrip: 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. |
|
x
 
MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include...
You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now! |
|
| Tuesday, December 31, 2002 | |
|
Two things have [re-]occurred to me as I near releasing my app to beta testing. The first is that - and I certainly learned this last year with the stand-alone Visual Basic application - it makes a lot more sense why so many apps seem half-finished when I start using them. If you had every feature packed in at version 1.0, well, that'd be great, but chances are you've missed more than one deliverable date. Of course stand-alones are much more difficult to manage than an app on "the living web", which you can cobble onto and improve daily, transparent to the client. More on this first point later. The second thing that hits me again is to be sure you like what you've got before you release. Each change to the application after 1.0 will need to worry about all the things you worried about before plus backwards compatibility. Makes me wish I had that rdbms backend for my app picked out and ready to go now instead of another infamous (and fairly well done) text file kludge. I'm just not sold on hsqldb quite yet. To expand on the point about leaving out features, in ye olde Digest Handler application there are two omissions right now for version 1.0 that drive me crazy. One is that the app's GUI isn't completely keyboard transversable. Technically it is keyboard transversable short of the multiline text components where you can't tab out of the component back to the other widgets. I'm thinking about cheesing out and just capturing "Shift-tabs" in multiline text components to move focus to the last widget. But to someone who appreciates vi, it's a far cry from perfect right now or even if I add that "fix". The second bit that bugs me is that you can't sort your emails. No way, no how. Right now you get them in the order Digest Handler finds them, which is awfully close to chronological order with most recent at the bottom. I think I'm going to allow people to reverse the sort in version 1.0, but I'd really like to break that open a bit more. Of course those are just the ones that bug me a lot. QA on user input is pretty sad, as is error reporting to the user. Often bugs are quietly logged in the error file without a peep to the user about what's going on, which is certainly less than ideal. But they don't bother me much. I'm firmly convinced that people are ready to forgive a few quirks to start using an app that addresses a need. Ever used Mozilla? Heck, even the VB IDE? :^) I've been told that there are two ways to make an "A" on a project. The first is to start as soon as it's assigned and to put the proverbial blood, sweat, and tears into it to make it look polished and professional. The second is to do it overnight and make it look like an "A"-calibre overnight project. The best way to make sure you don't make a quality project is to try and make an overnight project look like the "A" project you would have done had you started weeks before. To make each feature work just like I'd like would also mean I've practically written a fully-fledged email client, which is not my goal for version 1.0. In this context, the lesson from the paragraph above is to cut out for yourself what you have time to do and do that well. Don't try to make your work look like or act like something it's not. If I want an application that's that much more complicated - let's call it "99.44% complete" - I'll need to plan to invest that time. For now, I want an app that looks like version 1.0 because it is version 1.0 and I'll let the users (if any!) tell me where to start working next. posted by ruffin at 12/31/2002 07:59:00 PM |
|
| Saturday, December 28, 2002 | |
|
Looks like this is "the" ftp server to get if you're running Mac OS 9-. Seems to be written in Java too, no less. posted by ruffin at 12/28/2002 03:48:00 PM |
|
|
Object oriented programming is good. Heck, it's great. The code reuse that inheritance brings is a phenomenal paradigm shift for someone coming from strict procedural languages. After you realize just how inane the "Cats are mammals, Jane is a mammal, Jane and Cat both share the same fur attribute" introductions are, you've finally got object oriented programming and you're ready to make some real code that's set out "right". Problem is this fancy new programming style, even once you "get" it, leads one into a brand new land of infinitely more architectural choices. Depending on the application's size, there really can be a need for a straight-out code architect who may never actually type a line of code him or herself. I mean, this stuff gets messy, even with an awfully small application. The problem comes at you in two directions. You could, of course, cheese out and write what's essentially a procedural app using oo code. You can very easily pull out repeated code into objects that amount to no more than modules. And you can use globals and high-level objects to keep making the same sort of top-down apps you'd always made. You can even stub out interfaces to decrease how people roll their own objects to accomplish simple tasks. But when you do this, you're probably also missing out on some of what makes oo-style architecture great. The problem seems to be that most programmers don't use oo quite right even when they try, myself included. Do centralized objects put out listeners in every object (particularly GUIs) that might operate on them? Do GUIs have internal listeners that have hooks back into those same centralized objects that extend on some interface prescribed by the GUI object's constructors? Do you run a simple middleman object to pass parameters back and forth, at risk of that middle-object code looking like the worst assembly language spaghetti you've ever run across? Or do you split up your code into tons of manageable chunks, but risk having good interobject communication? Trying to code oo right is truly a mess. All I do know is that I'm finding it much tougher to write a good, "normalized" program in Java than it ever was in Visual Basic. It's ultimately just as easy to write something that works in either if you ignore IDE dis/advantages, but much much more difficult to defend why you put what object in which package and why the return values are primitive types instead of specialized objects or vice versa. It looks like I'm going to need to research conventional patterns (like those seen in this book) before I'm going to be able to make awfully good defenses of my application's architecture. At the same time it's a much more enjoyable challenge, even if my head hurts more often than it did before. OO done right is a thing of beauty indeed. But never before have I more starkly seen the lesson from Mythical Man Month - "Write one to throw away." I like to think of it as, "Write one that works now that you'll heavily refactor tomorrow," but the pain of having something less than perfect in OO-land is much greater than the same type of pain that's less frequent and less severe in VB-land. posted by ruffin at 12/28/2002 03:46:00 PM |
|
| Thursday, December 26, 2002 | |
|
Good heavens. Another fun afternoon of coding. I was going back to refactor my application's digest email parsing routine and make it use a more generic regular expression to find where one email began and another ended. Here's a quick word to the wise: "Not all regexp packages are the same." I was originally using a fairly old regexp package from Apache's Jakarta project (the people who brought you Tomcat). When I tried a few nice regexps that included new line characters - my original logic embarrassingly took things one line at a time - I started getting stack overflow errors. Bad news. Java 1.4 has its own regexp package now, java.util.regex, and even though 1.4 is not officially supported on Mac OS X just yet and will never be supported on Mac Classic - not to mention the headaches making sure someone's installed 1.4 and not, say, 1.2 on their Linux or Windows box - I thought I'd give it a whirl. Welp, the fine folk at Sun have apparently put on the blinders again. The regex package's newline is a UNIX newline any way you slice it. I was going to start substituting (\n|\r|\n\r) for each newline, but since I couldn't quite recall off the top of my head if that's exactly what I wanted and because 1.4 is hardly widespread, I decided to go looking for yet another regexp package. This, of course, is the smart thing to do. I almost stopped right then and there and wrote a custom method that just read bytes and got what I wanted, but I figured that would make for some particularly wack code. Back to Jakarta, it turns out. The ORO project is yet another regexp package supported by the Jakarta project. There's a cop out on the site that they keep both because "Options are a good thing and we will leave which one you choose to use up to you". Sheesh. If there's something useful in one and not the other, either roll the code together or at least tell us why we'd want to use one over the other. Anyhow, the ORO project seems to have a pretty good regexp package, even better than the one that comes with Sun's JVM in 1.4.1. Kinda sad. It's a real daunting task to weed through useful code these days. Though the parallel isn't perfect, it is nice to have Microsoft tested code behind many standard Visual Basic widgets. As a whole, I've found these to be more reliable than what I manage to dig up in the open source (but not GPL) world. And as a final random blurb, having two screens is much much better than one. If you're a programmer and have never tried using multiple monitors, do. Having email, IMs, and "research" URLs open on another screen away from your IDE and "real work" makes for a much more productive environment. You can get cheap CRTs for about $100 these days, and even 1024x768 makes for some good real estate for your "support apps". posted by ruffin at 12/26/2002 04:47:00 PM |
|
| Tuesday, December 24, 2002 | |
|
Ah yes, almost forgot. Finally grabbed a new laptop to take over for Whitey, my three-plus year old Celeron system I put together "from scratch". Whitey still makes a nice ottoman, and will eventually become my Linux test box, but going from a 533 Celeron to a 2.0 GHz Pentium 4 is great, especially when programming in Java using a Java-based IDE. And to continue my standard Mac hardware bashing, I got the 2 GHz, 20 GB HD, 256 meg RAM, DVD-playing, 32 VRAM-having, 14" screened machine for the same price as the cheapest iBook you can find at apple.com/store. I'm impressed by what I've seen of WinXP so far, and Gateway's done a decent job of rounding out what a typical PC consumer would need with the bundled apps. The battery life isn't nearly as good, and the screen I have now has a busted pixel, but so far I'm impressed with what I was able to get. I used to think the current model iBook was a good deal, but after using one in the Apple store and using this new Gateway for a day, well, I don't any more. posted by ruffin at 12/24/2002 07:11:00 PM |
|
|
Dang it. Lost my blog entry. Here it is, recreated Llama-style. Mission statements like, โBe usefulโ are useless. Useful how? Include adjectives you intend to measure. I replaced my resume โgoalโ with a motto/mission statement: โMaintainable, modular, documented, high-quality code delivered in a timely, customer-oriented fashion.โ Each adjective cries out for a few metrics. A little cheesy, but a heck of a lot better than, โBe the most useful employee for my employer.โ Beware of places that just strive to be [non-committal adjective here]. Sunโs online Java Tutorial is updating after all. I kept thinking Iโd caught a little change/tweak here and there, but small enough I wondered if I was crazy. When I saw this quote, I knew I wasnโt (at least not b/c of noticing these changes): Run RadioButtonDemo using Java Web Start. Sun used to have 1.0 and 1.1 versions of examples like this in applets. Nice to see theyโve finally given that straightjacketing technology up for JWS. Browsers were too constraining. JWS busts out of the browser and does you one better. Now the browser is a relatively xplat delivery tool. Very nice. posted by ruffin at 12/24/2002 07:03:00 PM |
|
| Wednesday, December 18, 2002 | |
|
Just to quickly document the fact, I finally made it in to an Apple retail store ("brick and mortar") this past weekend. Here are some quick impressions... Ran around the store trying out iPhoto on the different hardware they had set up. They had iPhoto set up well, with around thirty or fourty sample images you could move around and set up for export however you'd like. On a 600 MHz iBook through the 800 MHz G4 iMac, iPhoto's performance was still pretty poor. Made me feel better about my 500 MHz iBook, but worse about the Mac in general. Much of Apple's hardware, even with Quartz Extreme (each machine had 10.2.1 installed with plenty of RAM), still hasn't closed the gap with the slowdown introduced with the new OS. iPhoto on the dual 1 GHz PowerMac, however, I'm happy to say, ran like a dream. The Apple store was also nice enough to have an internet connection for each machine set up in the store. I was able to download and install Netbeans to give it a shot. At first I was shocked at how slow it ran -- editing Java code seemed as slow on the dual GHZ as what I was used to on my 533 Celeron with Windows 2000. Then it occurred to me that I was using Eclipse on the 533 when I program in Java, and that Netbeans runs quite a bit more slowly (*duh*). Unfortunately, this means Netbeans runs about as quickly on the dual GHz PowerMac as a single 1 GHz Pentium, give or take (purely going on feel after just a minute or two of use). Certainly fast enough to do your programming, but still not fast enough to make me want to develop Java primarily on the Mac, and sure as heck not an affordable alternative to Windows/Linux on x86 hardware just yet. And finally, there was just enough software on the shelves, somewhat tastefully displayed, that I think you wouldn't not buy a Mac because of software deficiencies. That revelation was probably the most positive experience I had in the store. Microsoft Office was sitting right there, front and center, and even the games rack had enough of [admittedly last-year's favorites on Windows] a selection to make a prospective Mac user go ahead and pull the trigger. Granted, these aren't software packages I'm dying to purchase (AppleWorks/AbiWord does me just fine), but for a typical home PC user it was good to see. Hopefully in another year the consumer-level Mac will have enough juice to run the more processor-intensive iApps (like iPhoto and iDVD) well. With the dual processor PowerMac, luckily, hardcore Mac users in the present finally have the power for an OS X equipped Mac to quite nearly make sense as a solid PC upgrade. Now if the new G5 would just finally make it to center stage... posted by ruffin at 12/18/2002 11:15:00 PM |
|
| Monday, December 16, 2002 | |
|
First off, I apologize. This blog got too long to edit and spellcheck somewhere along the way, and I need to get to work. So the quality of writing here is probably even lower than usual, if that's possible, as I haven't even lazily proofread it like I usually will. Found this blog during a search on Google for vim and Eclipse. It had a link to a site called JavaBlogs which in turn led me to this reltively interesting comment on yet another blog (boy these things are like roaches! Yes, that comment would certainly include this blog as well): I liked his comments (scroll down a bit) about the "Java Stigma" in terms of being able to do client apps. I'll throw some more points out there... Try using JBuilder or IDEA. These are monster client apps, written in Java that both look and feel excellent. People really need to get over the idea that Java desktop apps are either slower or look crappy. Couple of comments. Swing (Java GUI tech I've been ranting/whining about) is slow, both to display and to develop. Apple has gone to great lengths to hardware accelerate Swing on its already horrible slow platform, and IBM's SWT is just another attempt to speed up a slow system. Remember, the question's not so much "Is Swing fast enough," as it is, "Is Swing as fast as the native apps the user's used to using?" Often -- usually -- the apps are noticably slower. Processors have gotten fast enough that many "day-to-day" activities in a Swing app might not be as noticably slower as they were before, but there's always some tell-tale sign, from startup time to a cluttered GUI causing slow-down or too many widgets updating at once that pegs the processor and kills other running apps (mp3 players being one really clear indication of when the processor is swamped). Swing is also slow to develop for. It's not intuitive. And this is both on the design side and for users. On top of its goofy, roll-your-own event handling (admittedly I over-whined a few days ago, but it's still not good), a good developer needs to try and force Swing's square peg into the round hole of native OS expectations its end users have developed. Also recall that JBuilder and IDEA are apps written for pretty techno-savvy users. Limewire is about the only Java-made client app I can think of that gets lots of real end user use, and I believe its success comes more from its kissing cousin relationship with the Gnutella protocol than any great user experience. (Furthur is another neat client app, but it's pretty unprofession-looking when it comes to UI, and isn't nearly as widely used as Limewire). Geeky users don't have these native OS expectations and can adjust when you, say, have to use "Ctrl-S" to save instead of "Apple-S" or when other keyboard shortcuts don't behave as they do natively. Heck, even hard-core technie Joel Spolsky whines about UIs that are marginally different xplat (though I believe he's got a bit of "dementia-level perfectionist" in him). Here's a comment he made recently about XUL and Mozilla: Even my favorite bugaboo, Alt+Space N to minimize a window, works in Mozilla; it took them long enough but they did it. So that IDEA and JBuilder seem like decent client apps to a programmer isn't a good measuring stick on the successfulness of Java for the typicaly home PC user. Between Swing's inferior performance to native, the difficulty in producing a good, native-like user experience, and the yet unmentioned-if-farily minor pain of getting a JVM onto a user's system, Java's still not quite ready for the client-side prime time. Note that these issues are part of why I think Sun should try harder to promote a Java platform that doesn't try to act percisely native and where users expect Metal Look & Feel application and expect to use Control as their main modifier key, expect to use JFileChooser to open and save files, etc. I've always wished Sun would make a Java OS and release it for x86 hardware with highly optimized calls, not so much to make money but instead just to make a point. Java is an OS, a look, another platform. *sigh* Shifting gears... At any rate, was originally searching to try and see if there's any way to integrate vim with the Windows version of Eclipse, which apparently claims somewhere to support OLE compatible editors. Course even if I could get it working, I'm pretty sure it'd be as unpleasant an experience as hooking it as the editor in Visual Basic 6's IDE. The files don't open up in vim in the same mutli-document interface, but instead, when a file is double clicked in the IDE, they are opened in a new vim instance. Not the best thing I can imagine. I'd like to find some time now to write up some Java vim clone that just supports the commands I use about 70% of the time, like s, p/P, r, ^, $, y, and v. Of course supporting :w is pretty important, and is not supported by the crappy Java vim clone that I can find on sourceforge right now. That editor apparently is only really targetted for JBuilder as well, as far as I can tell. That said, its activity percentage is above 50%, which isn't bad. But as a standalone I've found jVi to be nearly useless. At any rate, I believe it'd be relatively easy to write an event listener for text widgets that would, if designed to be from the start, be pretty easy to port to C# and Windows Forms as well. I'm awfully confident #develop wouldn't have much problem integrating with the new editor, though editing Visual Basic 6 wouldn't benefit much at all I'm afraid. Hopefully, though I haven't read much about SWT other than a few "What is SWT all about?" kinds of docs on Eclipse.org, it'd be easy going to get the event listener going there too. Guess I'll put that project right behind porting Futhur to OS 9, writing an Atari game, finishing up the Java app to help port to Java 1.1, and taking a nap. posted by ruffin at 12/16/2002 12:08:00 PM |
|
| Thursday, December 12, 2002 | |
|
Here's a cute resume blurb from some random schmoe whose weblog was recently quoted over at JoelOnSoftware.com: EXPERIENCE The beauty here is that this "job" is basically just someone saying, "I'm working on open source software," which, when you combine all the job interviews he's had that he quite openly lists on his blog, translates to, "I'm working on open source software until I can land another job." The next logical extension is, "I'm pretending to help on this open source project until I'm gainfully employeed so as not to look like I'm wasting time. I may even intend to continue helping once I've been hired again." Here's the neat/brilliant part -- others are helping. There's a board of directors, a Systems Architect, a Community and Partner Relations manager, all sorts of stuff. And even if they completely drop the ball on the only product "OSA" is making, they still gets to be the lords & ladies of a right grandiose open source project. The source is out there just waiting for someone to "pitch in". At any rate, I'm impressed. It's like a face-saving [hopefully temporary, I'm sure] elephant dying ground. Get a few friends together, draw positions from a hat, and have everyone write up some text for someone to shove into html and publish online. Heck, some of these guys even have good bios. Good to get them on the team, at least on paper. Brilliant. Perhaps I'm too cynical (of course I'm too cynical), but nobody -- and I mean nobody -- advertises features before they've written working code in the post-venture/madman capitalist era. Not even open sourced schmoes. Reminds me of that initiative a while back where some old schmoes that helped make Macintosh were going to create some brilliant UI for Linux, a relatively desktop-unfriendly system. They failed; Apple's OS X did not. But if you'd believed their hype, taken together with their resumes, you'd have really thought the opposite was going to happen. Also a little like that Transmeta Crusoe chip, which is actually doing fairly well, I think, all things considered, having found its way into a number of mainstream notebooks. But it hardly delivered on the hype, even with several really big names, and shows just how hard it is to go from concept to concrete. Actually it reminds me even more of how the government works, but in this government this plan is, sadly, a receipe for success. Anyhow, if you're currently unemployeed, get together six or seven other people in the same boat (or who want to add something to the resume), create some vaporware (it's really easy), and slap together a decent-looking website. Poof. Instant job-limbo-which-does-not-quite-look-like-job-limbo-and-that-you-can-actually-put-on-your-resume. And now, back to work on my trailware app that, when it has delusions of grandeur, thinks eventually (years out) it'll be awfully similar to the features of the OSA application. (Yes, there's some funnin' o' myself in this last paragraph here.) But honestly, if there's one thing I learned quickly it's that you can't, no matter how wonderful the people you attach to a project, make something great out of simple grand intentions, no matter how much money and time and talent you burn. Aim small and work your way up. Unless you were just in it for the resume to begin with. Brilliant. posted by ruffin at 12/12/2002 11:23:00 AM |
|
| Tuesday, December 10, 2002 | |
|
As I've said before, I'm not enamoured with Swing though it remains the lesser of all GUI evils when making a crossplatform app with Java. I believe my biggest gripe is the "event-dispatching thread" set up which causes event sparked by your GUI to occur in a different thread than everything else. Want a button to cause you app to count to one million (insert a more realistic, time consuming task)? Without learning about threads and how to start your own, your GUI is going to sit there, locked up until the app's done counting. Annoying. In spite of this shortcoming, Sun's best solution on using threads with swing is, "Don't use them." Annoying. It really makes me wonder if the criticism I'd seen that Swing was intended as a means to debug database apps wasn't really that far from the mark. Threads are not incredibly difficult, but they are quite a bit of overhead for a GUI. I can't even update the GUI from the GUI-invoked process to tell the user I'm, say, 43% done without setting up another thread, making all sorts of objects "final" so that I can pass them to inner classes, etc. If there were the only problem with Swing, I'd be a happy camper. I'd write a quick blog condemming how unnecessarily difficult it is for me to pass and retrieve objects with all these wacky threads flying around to cure FGS ("Frozen GUI Syndrome") and be done with it. But the shortcomings don't end there; Swing is also unnecessarily unintuitive and lacking many of the "nicities" you'd expect from a mature GUI widget toolkit. Rather than digress into another pre-rant mini-rant on the topic, and also so that I can remember where this page is when I swap computers (and lose my bookmarks), take a look at what you need to do to add, say, a JButton to a JTable. Or, even simpler, to have a JTable that sorts when a user clicks on the title at the top. Even REALbasic did that for me without a single line of code. Sheesh. Full rant to come, I'd imagine. In other news, my 100 MHz Pentium laptop is loaded with Win98, VIm, Ultra-Edit, and HTML-Kit and is ready for VB 6 and SQL Server. After that, it'll probably explode. Poor thing. posted by ruffin at 12/10/2002 08:13:00 PM |
|
| Tuesday, December 03, 2002 | |
|
In reference to yesterday's book-length commentary on Swing, it looks like Sun both agrees with me on the sad state of the Windows Look and Feel that comes with Sun's Java Virtual Machine for Windows. From their site: The ideal Swing application running under the Windows look and feel would be indistinguishable from its native running counterparts, however due to both changes in the native Windows look and feel (Windows 98, Windows 2000, etc.) and atrophy of our existing Windows look and feel implementation, this has not been the reality. Luckily with Java 1.4, they've also apparently done something about it, and the above link details what's been changed. Looks like they've done a much better job than before, if the next quote (same link) is any indication: In other words, if a running Swing application detects that a particular user preference (such as Menu fading) doesn't exist, then the windows look and feel will not execute that feature. I've been using 1.3.1 to stay current with what I can find crossplatform (Mac OS X currently the limiting reagent). I'll certainly have to check 1.4 out -- not only for this new look and feel but also for new drag & drop functionality, among other pluses -- once version one of ye olde app has been released. posted by ruffin at 12/03/2002 08:16:00 AM |
|
| Monday, December 02, 2002 | |
|
I've been constructing the GUI to my trialware app, and I'm not real sure if Apple's done me a favor or not. There are quite a few little quirks that a user expects on one platform that might not be commonplace on another, and these are the final details a software designer has to conquer that really make the Java mantra of "write once, run anywhere" a bit of a misnomer. When you use VIm, for instance, you have to learn a whole new way of navigating text. To get to the end of a line in VIm in, um, non-edit mode, you type "$". To get to the beginning of the line, you type "^", of course! To move forward one "page", you type "Ctrl-F". Backwards a page is "Ctrl-B". For the most part the "Home" and "End" keys work as expected, but there are a few extra shortcuts. Similar things exist for most any text area in Macland. Whether you've got Mozilla, AppleWorks 6, or BBEdit (probably the most popular text editor on the Mac) open, every long-time Mac users knows that "Apple-[cursor right/arrow key]" takes you to the end of a line of text, "Apple-[cursor up]" take you to the first line of your text, and so on for the opposites. Applications that stray from this path, like Microsoft Word 98 on the Macintosh, frustrate Mac users. You don't want your app to follow suit. If you have a keyboard/monitor switch running into several computers like I do, you'll quickly notice another change from one platform to the next. In Windows, you'll find you typically use "Ctrl-S" to save a document but when you use the Macintosh you'll use "Apple-S". This Control-to-Apple key switch happens for most any command when you switch over, like cut, paste, and undo. Now on Apple keyboards, often the Apple key has moved to match the Control key's location on keyboards designed for PCs, so your muscle memory isn't caught so off guard. When sharing a keyboard, however, the muscle-memory learning curve is a bit more pronounced. Using what is essentially the Windows key as the Control key replacement is a little disorienting at first, and requires your thumb to move in ways it's never moved before. Now consider using Sun's Swing to build your Java GUI. You'll find the GUI behaves the same crossplatform! Super, right? Well, as you may have guessed, not exactly. There are some keyboard shortcuts that come by default with the cross-platform version of the Swing widgets, like cut and paste. On Windows and Linux the "Ctrl-C" and "Ctrl-V" built-in shortcuts are quite welcome, saving you quite a bit of code. On the Macintosh, however, you've got everything wired wrong! Not only do you have to wire up new shortcuts for cut and paste, you should probably, just to be on the complete up-and-up, unwire the Control key shortcuts so that they don't work on the Mac! Sheesh! What a mess! But before you get too far into extending JTextArea (or, if you're really clever, JTextComponent), check this: Apple's done all the work for you. By using the "UIManager.getSystemLookAndFeelClassName()" method, Apple will default your Swing implementation to Aqua, Apple's new, fancy-smancy widget toolkit on Mac OS X. "Apple-[cursor down key]" will take you to the bottom of your text, just as you expected, without a single extra line of code. "Apple-V" pastes; "Ctrl-V" does not. Great! All my user interface problems solved with a single line of code! And the app looks groovy too! Right? This isn't a good thing. Apple didn't go far enough - or, if they aren't going to go farther, they've gone too far in the first place. Consider the issue of dialogs. The Swing-Aqua dialogs don't follow the "Aqua Human Interface Guidelines" (see above link for doc). Here's one of the slip-up's: The application icon. Because of the Mac OS X window layering model (described in "Window Layering" (page 70)), an icon is necessary to make it clear to the user which application is displaying the alert. Even though many dialog types are the same between Swing and Aqua, the Aqua-Swing dialogs just look like their typical, Metal counterparts stuck on Aqua frames with a slightly more stylish icon. (Metal is Swing's crossplatform look and feel that does a great job acting the same - and I mean exactly the same - wherever it's run.) This is a pretty obvious and tell-tale sign that your app isn't native, the goal of the System look and feel. Other issues include that Control shortcuts in menus still come up with their Control masks, for instance. So if your menu said "Control-S" for Save with the Windows or Motif Swing look and feel, it still says "Control-S" in Macland. This also means that a keyboard shortcut of "Ctrl-V" in a menu for a JTextComponent means both Apple-V and Ctrl-V will paste in your app. Another problem: The default font size doesn't scale real well in labels. Now you have to recheck the appearance of any label once you've switched to Aqua to make sure "Enter your password" hasn't become "Enter your pass...". The Menu bar is still displayed as part of the frame, not at the top of the screen like a native Mac app. Not to mention all the considerations for rewrites of you application's manual and help file. Everything's different now, and you'll have to rewrite your manual to match. Do I really want to do things half-Apple's way? I like what Apple's trying to do, I really do. They'd like to make it easy for me to create a Swing UI in Metal and, with the change of a single line, run it on the Mac the way Mac users expect. Unfortunately they're nowhere close. Though there are ways to fix every problem I've mentioned, they each require you get away from the idea of a 100% Pure Java application (a program which, not surprisingly, Sun has "End of Life'd"). To sum up, and to try and make it sound like I'm not whining about my gift horse's crooked teeth, Java GUIs shouldn't try to look like native applications and Apple's wasting our time trying. The whole "[Native] System Look and Feel" idea just isn't going to cut it. Have you seen the Windows look at feel that comes with Sun's Windows virtual machine? Barely updated if at all since Windows 95, it looks horrible and wouldn't convince anyone that you've got a native Windows app. Could be worse; take a look at [my app, such as it is now, in] the Motif look & feel. As a randmo AIMer said to me, it looks great if you'd prefer to pretend you're stuck living in a timewarp taking you to 1986. (It's supposed to look like Sun's Solaris operating system. Okay, more specifically, it's trying to look like a really old version of what become this. Actually, looking at these "updated Motif" shots, this look & feel might be the most on the money! But, um, I'm going out on a limb and saying nobody's "native" apps look like this on a desktop machine, not even most Linux desktops.) It's too much trouble to emulate native platforms, and Java shouldn't be scared to be its own platform. Swing should reflect this. Hey, Sun, update Metal. Help it run crossplatform in a way users expect. Forget looking native and forget keeping it simple. Work with Blackdown.org and Apple to get virtual machines that run Metal GUIs in a way local users expect. And help truly bring Java GUIs out of the niche of debugging database applications into the realm of the everyday client application. Phew, rant. Done. posted by ruffin at 12/02/2002 08:13:00 PM |
|
|
| |
|
All posts can be accessed here: Just the last year o' posts: |
|||||||||||||||||||||
|
||||||||||||||||||||||
|
|
|
About Our Author