by date
Plan for James Lupiani
Plan for James Lupiani
| Name: | James Lupiani |  |
|---|---|---|
| Date Posted: | Sep 21, 2005 | |
| Rating: |  Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for James Lupiani |
Blog post
If you're writing an application that's primarily GUI-based, your app should not require or default to running from within a CLI window.
It's really starting to irk me. Maybe it's console elitism, maybe it's printf-codependence, or maybe it's just laziness.
Let me give you a few examples in recent memory that I find particularly distasteful:
1. Blender 3D - Blender has a bad enough reputation for the learning curve, so I won't pick on it too much. In its case, the only saving grace is that the console window might occasionally provide useful debugging information. That being said, I think there may be a number of more elegant solutions available in, for example, every other 3D package known to humankind. There's a relatively obscure NURBS modeler known as Rhino3D that relies heavily on a command system, but it deals with it by integrating the console into its UI.
2. Stani's Python Editor - I decided to give this another try earlier today, in light of the sheer amount of feature integration it offers. I couldn't hold back a groan when I first ran it and a console window popped up. I would have trashed it without a second thought, but it turned out that getting rid of the console window was a simple matter of changing the shortcut to use the GUI python interpreter instead.
3. Torque - This has been coming up as a topic in the forums for what, four years now? There is absolutely no reason release builds of Torque games (especially official GG demos!) should be set with /subsystem:console. The logging facilities and in-game console are more than adequate. You want console output on a second monitor? I suggest you research an ancient app known as tail.
You're probably thinking, "what the heck is this guy on about? All you have to do is change--" Let me stop you right there. Even if everybody knew how to change the behavior for all these apps (and could indeed recompile those that require it), they shouldn't be forced to. Another response I've heard is basically that it's not a bug, it's a feature. That's like a real estate agent trying to put a positive spin on a run-down house by calling it a "fixer-upper." Here's why...
GUI applications that launch from within a CLI window give off a strong initial impression of being unpolished or outdated. Non-technical people that are old enough to remember DOS usually say something akin to, "This thing runs on DOS? How 80's is that?!" Windows users in particular end up having to deal with two separate taskbar items to click and Alt-Tab between. Closing just one of the windows will typically kill both of them. This tightly-coupled behavior is a usability faux pas that should be dealt with sooner rather than later in software design.
So, please, take that extra ten seconds and do it right.
Let me give you a few examples in recent memory that I find particularly distasteful:
1. Blender 3D - Blender has a bad enough reputation for the learning curve, so I won't pick on it too much. In its case, the only saving grace is that the console window might occasionally provide useful debugging information. That being said, I think there may be a number of more elegant solutions available in, for example, every other 3D package known to humankind. There's a relatively obscure NURBS modeler known as Rhino3D that relies heavily on a command system, but it deals with it by integrating the console into its UI.
2. Stani's Python Editor - I decided to give this another try earlier today, in light of the sheer amount of feature integration it offers. I couldn't hold back a groan when I first ran it and a console window popped up. I would have trashed it without a second thought, but it turned out that getting rid of the console window was a simple matter of changing the shortcut to use the GUI python interpreter instead.
3. Torque - This has been coming up as a topic in the forums for what, four years now? There is absolutely no reason release builds of Torque games (especially official GG demos!) should be set with /subsystem:console. The logging facilities and in-game console are more than adequate. You want console output on a second monitor? I suggest you research an ancient app known as tail.
You're probably thinking, "what the heck is this guy on about? All you have to do is change--" Let me stop you right there. Even if everybody knew how to change the behavior for all these apps (and could indeed recompile those that require it), they shouldn't be forced to. Another response I've heard is basically that it's not a bug, it's a feature. That's like a real estate agent trying to put a positive spin on a run-down house by calling it a "fixer-upper." Here's why...
GUI applications that launch from within a CLI window give off a strong initial impression of being unpolished or outdated. Non-technical people that are old enough to remember DOS usually say something akin to, "This thing runs on DOS? How 80's is that?!" Windows users in particular end up having to deal with two separate taskbar items to click and Alt-Tab between. Closing just one of the windows will typically kill both of them. This tightly-coupled behavior is a usability faux pas that should be dealt with sooner rather than later in software design.
So, please, take that extra ten seconds and do it right.
Recent Blog Posts
| List: | 10/16/06 - Community Weekend & Frozen Codebase 11/07/05 - Plan for James Lupiani 09/21/05 - Plan for James Lupiani 08/11/05 - Plan for James Lupiani 11/28/04 - Plan for James Lupiani 02/26/03 - Plan for James Lupiani 10/27/02 - Plan for James "Defiant" Lupiani 05/25/02 - Plan for James "Defiant" Lupiani |
|---|
Submit your own resources!| Nigel Hungerford-Symes (Sep 21, 2005 at 04:22 GMT) |
When I run Blender under Linux, I run it from a shell window to get debug info.
If the windows version didn't have a console window I wouldn't get all those nice reason why Python just choked, the Torque exporter wasn't set up properly or how far through my yafray render is.
If it plugs into the standard "cout" and that is available on the 6 different platforms it runs on, why go to the bother of coding a second window or using valuable screen real estate in one window to do the job that is already done with a console.
Plus, you can pipe the info to other apps sooooooo easily that way.
If people fear the "DOS" prompt then they should stick to the XBox :)
| Andy Schatz (Sep 21, 2005 at 05:19 GMT) |
Andy
| Matthew Langley (Sep 21, 2005 at 16:37 GMT) |
I agree with the demos... but for release builds (that is if your talking about the one that comes with Torque when you download it) (which really is just a start build for Torque as a dev tool) I think the console is fine. If you don't know how to take out the console then you really need to if you want to release a game and should look at it as a learning experience. At least thats my opinion :)
Edited on Sep 21, 2005 16:38 GMT
| Anthony Fullmer (Sep 21, 2005 at 18:17 GMT) |
| James Lupiani (Sep 21, 2005 at 23:11 GMT) |
You can easily redirect stdout to a window within the application itself, avoiding the coupling problems but retaining the functionality. In the case of Blender, which has excellent layout flexibility, I'd put the console in its own pane. You could then watch the progress of your script's execution without changing focus or using a window manager to pin the console on top of all other windows.
What I was trying to get at towards the end there is that I do know how to take out that prompt. Depending on the system, it's either a large hassle (download and rebuild Blender?) or such a small fix that it really should have been done to polish off a production release anyway (as in the case of SPE).
The "deal with the prompt or get out" argument would be a great one, if it were for purely command line apps. The problem here is crossing between the two domains and creating a counterintuitive link between them. A fair compromise would be to allow the creation and destruction of the command window without destroying its associated GUI.
You must be a member and be logged in to either append comments or rate this resource.
