From owner-freebsd-chat Sat Jan 29 20:33:31 2000 Delivered-To: freebsd-chat@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id B15D515314 for ; Sat, 29 Jan 2000 20:31:32 -0800 (PST) (envelope-from daemon@bigeye.rhein-neckar.de) Received: from bigeye.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id FAA16372 for freebsd-chat@freebsd.org; Sun, 30 Jan 2000 05:31:31 +0100 (CET) (envelope-from daemon@bigeye.rhein-neckar.de) Received: (from daemon@localhost) by bigeye.rhein-neckar.de (8.9.3/8.9.3) id EAA16760 for freebsd-chat@freebsd.org; Sun, 30 Jan 2000 04:25:52 +0100 (CET) (envelope-from daemon) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: GUIs are flawed Date: 30 Jan 2000 04:25:51 +0100 Message-ID: <870avv$gba$1@bigeye.rhein-neckar.de> References: <20000129163556.A69961@tougas.net> To: freebsd-chat@freebsd.org Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Damien Tougas wrote: > One of the beauties of Unix, and one the many reasons that it is so > powerful is the power and flexibility that one has in a command > line shell. Mike Gancarz has a wonderful little book out, _The Unix Philosophy_, which examines these issues. Recommended. The command line allows you to *interface* programs, mostly through pipes, and to use files as data sources and destinations. Yes, programs need to hammer out all data as flat text streams and reconvert them into internal representations. Not as sexy as exchanging persistent objects in binary form, but it works. Since you can interface programs, you can use the approach of many small specialized tools that can be combined as needed. Now add a simple language with basic flow controls and text substitution (sh) and a dependency evaluator (make). Presto you have a very powerful toolchest to *automate* tasks. GUI applications are centered around an event loop to read user input and return results as bitmap displays. There part of the larger class of *captive interfaces*. GUI applications don't lend themselves to interfacing to each other or being controlled by another program. As the toolchest approach breaks down, GUI applications need to handle ever increasing amounts of functionality themselves. You get runaway bloat. GUI applications are of course still useful at both ends of the processing pipeline, i.e. users inputting and displaying data. Integration of the processing step is the point where development starts going wrong. > Don't get me wrong, I think that GUIs defenitely have their advantages, > but I also think that perhaps there needs to be a paradigm shift in the > way that they are designed in order to sustain future development. I'm impatiently waiting for a much greater paradigm shift. The step towards post-GUI interfaces. GUIs have been with us for two decades now, basically unchanged except for minor cosmetics. The concept is stale. GUIs can't be the endpoint of all interface development. What's next? > Why can't someone create a GUI framework that works more like a command > line? -- Small programs/applets that are easy to maintain on their own, > but which can be plugged together by the user at will to accomlish > the task at hand. If you talk to Torben Weis (KDE) about his KOffice project, he'll tell you that he indeed implements such an approach, and I presume this is more or less rooted in KDE's workings in general. He has working demos to illustrate this. -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message