[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Saturday 26 November 2005 2:50 pm, Simon Waters wrote: > But Zenity and friends aren't portable (well aren't as universally > available as a Posix Shell, I'm sure Debian GNU/Linux with GNOME will > run on pretty much all the hardware being used to read this message with > enough effort). Even my iPAQ. :-) However, this illustrates my basic objection to using a GUI for a script task. GUI's keep changing. To record a sequence of GUI instructions and repeat the task unattended requires a complex set of non-portable mouse events. To record a sequence of command line instructions into a script simply involves copy and paste from bash history. If you can do something once on the command line, you can do it again and again - attended or unattended - simply by copying the command line into a script. You can't do that with a GUI. (Which is exactly where this thread started.) > I'm not aware of a small portable set of regular dialogs for simple > cross platform scripting covering Windows/MacOS/X/consoles/GNOME/KDE, > although it would seem kind of handy. Java was meant to go that way - but it doesn't. The iPAQ (for one) can't run Java. Despite all protestations, Java is not portable in the way that Gnome is portable (which does run on the iPAQ and Win32). Now if Java could be broken down into smaller units - as Gnome can - then we might have a solution but whilst the JRE remains both non-free AND monolithic, Java remains a dead end. > Which is where Neils comments about libraries comes in, to get any of > this GUI functionality depends on a hell of a lot of environment (am I > in a shell, do I have a console, am I in X, am I in Gnome, am I in KDE, > am I in Win32, what do I do if none of these are true, what do I do if > several appear to be true....). Even if you leave all those decisions to the user via option after option, you will ALWAYS need a default case that falls back on the only common denominator in all these systems - a command shell. GUI wrappers around shell code isn't what I felt Matt was seeking. Frankly, I don't subscribe to the tired old mantra that more users is best. We've had this discussion here many times, so here's a potted history for those new to the list. 1. The simple sum of the number of users is irrelevant. Simply increasing the number of bums at keyboards does NOTHING to improve the OS. We desperately need MORE people writing better shell scripts and programs, better GUI applications, better RAD tools, better device drivers, better interprocess methods and better documentation. Without these, it really does not matter how many users we attract, the OS will die for lack of development. 2. GUI applications necessarily hide some functionality that could be performed via the command line. One reason is above - repeating tasks (especially unattended). 2a: Before you all shout 'macros', macros are not portable, they do not work between programs and cannot be used unattended without some form of script (typically using a command shell) to start the only application that understands them. Try running your GUI macros via cron. Even better, try writing a portable set of macros that export data from one application and keep it updated in another on a different platform. 3. Choice is central to freedom. Restricting choice for any reason is A BAD THING. (tm). Restricting the functionality of a program by only implementing those functions that fit within a GUI is simply BAD DESIGN. OSX is a case in point. Core command line tools (like man) are deliberately broken just to fit in with a design model arising from a GUI perspective. Stuff the GUI, let's have core command tools that we can actually USE! OSX is the single worst development platform I have *ever* used - and that includes Windows 3.0 and ZX BASIC. 4. There is plenty of room for BOTH the command line and the GUI. Some things work best in a GUI, some simply cannot be done without a command line. A general rule of thumb is that increasing complexity and flexibility favour the command line. Simplicity and vendor lock-in favour a GUI (ask MS). We don't want complex GUI's, we don't want lock-in. 5. Free software can only persist if it is simple for new users to become new developers. This is of immense importance. We are where we are because users have switched from other systems and become developers of free software. We cannot support expensive training programs for all prospective developers. We cannot expect every new developer to have a BSc in Computer Science. A lot of code comes from part-time, self-taught, volunteer members of our community, like me. We must strive to encourage and support ALL such volunteers or we face seeing our favourite OS being left behind by the mega-wallet proprietary houses. 6. Free software must be defended at all times and at all costs. There are enough people out there who would like to see free software die without us being at each other's throats. Healthy disagreements are fine, but trolling is not. Don't be a parasite - get involved and do something to improve the community. It is our community, it includes everyone and it is up to everyone to pull together against common threats like DRM, software patents, non-free licences / EULA and those parasites who would abuse our freedom without giving anything back. The sad fact is that adding more bums at keyboards simply increases the numbers TAKING without increasing the numbers GIVING. Take-take-take is fine if the developers are charging mega-bucks per installation (like MS). If *you* value the freedom of the GNU approach, it is incumbent on *YOU* - as an individual - to give something back to those individuals who have given you so much. You cannot condemn SCO and then do the same by leaching off others. Get out there and get involved. 7. Free software favours small tools crafted together into a more expansive whole. This is a Unix tradition and it has served us well. Monolithic GUI programs favour vendor lock-in and can easily get left behind. If you build a command tool, write it so that a GUI can be added. If you write a GUI, write it so that it accepts usable command line options. Reuse code at ALL COSTS. We share code so that no-one needs to write it twice, so USE LIBRARIES and create your own. Make four small applications instead of one large one and use libraries and interprocess methods to build a larger, more flexible, unit. Then, if someone else comes along with a fifth unit, there can be several new applications plus an extended large one. Think modular, think portable, think standards. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp8EUKqOytUe.pgp
Description: PGP signature