10 ms·

> I don’t see how someone would argue that a photo editing app, music workstation, IDE, CAD program etc would somehow be better because it had a graphical UI th

by ajuc 8y ago

> I don’t see how someone would argue that a photo editing app, music workstation, IDE, CAD program etc would somehow be better because it had a graphical UI that was layered “on top” of something that was textual? inkscape has "headless" cli mode, I've used it for batch processing svgs, and (independently) seen it used in similar manner in one of the companies I worked for. I use mainly mplayer on linux for playing music/videos and simple processing (for example changing speed or encoding). You can argue it's not CLI app because it opens a graphical window, but it has text-only interface and additionally some gui, exactly as the article suggested. Emacs and vi serve as an ide for many people, but these are just text-mode GUIs, what's important is that some of their capabilities can be also used in batch mode (for example - let's say you want to refactor 100 methods in 30 files - woudln't it be nice to be able to write a small for loop and call some cli app to do that?) I don't know much about CAD but I suspect text mode for doing repetative parametric work would be useful as well.

alkonaut 8y ago
I’m not arguing that scripting or batching is not useful - I’m only arguing that that a CLI is usually not a good base to build the GUI on top of. Having a libsomeghing and a something-cli and something-gui is a perfectly good solution, but usually not if the GUI calls the CLI instead of the lib.
- ajuc 8y ago
  > Having a libsomeghing and a something-cli and something-gui is a perfectly good solution That's what he proposes? > The GUI wrapper should be a separable module. If they're plug-replaceable, the application isn't irretrievably wedded to any specific GUI technology... > This means your program should be runnable both with and without the GUI present, and accept input from a mouse or under programmed control. Preferably that means both a shell-level interface for convenience and a C-level interface for efficiency; Perl programmers could elect either method. That way, naive users can use push-button GUIs, blind users can use Braille terminals, and sophisticated users can program solutions to intricate problems. Basically he says we need to use model-view-controller architecture to write desktop applications.

by ajuc 8y ago

alkonaut 8y ago

I’m not arguing that scripting or batching is not useful - I’m only arguing that that a CLI is usually not a good base to build the GUI on top of. Having a libsomeghing and a something-cli and something-gui is a perfectly good solution, but usually not if the GUI calls the CLI instead of the lib.

ajuc 8y ago
> Having a libsomeghing and a something-cli and something-gui is a perfectly good solution That's what he proposes? > The GUI wrapper should be a separable module. If they're plug-replaceable, the application isn't irretrievably wedded to any specific GUI technology... > This means your program should be runnable both with and without the GUI present, and accept input from a mouse or under programmed control. Preferably that means both a shell-level interface for convenience and a C-level interface for efficiency; Perl programmers could elect either method. That way, naive users can use push-button GUIs, blind users can use Braille terminals, and sophisticated users can program solutions to intricate problems. Basically he says we need to use model-view-controller architecture to write desktop applications.