https://bugs.kde.org/show_bug.cgi?id=481166
Flossy Cat <flossy-...@online.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INTENTIONAL |FIXED
--- Comment #10 from Flossy Cat <flossy-...@online.de> ---
(In reply to David Jarvie from comment #9)
> I'm well aware of the benefits of how UNIX tools can work together to do
> more complex tasks, which for example allows versatility in scripting.
I do not doubt that you are aware of this – nevertheless practice and
experience changes the awareness: I use these mechanisms from the early
eighties – roughly 4 decades – more or less on a daily basis, all the while
monitoring my computer usage and refactoring it into automatable sub-tasks …
I use this not only for scripting but my command-lines regurlarly contain
pipes, variables, history references, redirections, …
> But GUI applications as they currently exist generally don't lend themselves
> to
> this, due in part I'm sure to the need for user interaction using a mouse.
IMHO a misconception:
The CLI needs interaction too – no command executes without pressing the enter
button, not to speak of the arcane key-press sequences needed before to have a
command doing anything complex.
The core is clever inter-process communication and the pipe as well as
environment variables are an ingeniously clever IPC mechanism.
With this and some scripting you can go a long way with existing GUI
applications:
I have large test-beds which fire up an editor for documentation, the load
generators and performance monitors (both visual and more detailed non-visual).
With a keyboard macro in »vi« you trigger both a screenshot as well as a
timestamp (more precise: the name of the screen-shot) and can document the
observations. You close the editor – the tests are stopped, performance data is
collected, processed in various ways and presented visually in GNUplot sessions
as graphs which interactively can be fine-tuned, e.g. by selection of time
periods, annotations, manual fitting of the parameters of mathematical models
of the investigated systems, etc.
(From the tool choices you easily see: these test-beds are decades old and used
since ;-)
>From the outside this looks like an elaborate framework or application – but it
isn't.
IPC directly between GUI applications is of course more difficult.
>From the era of mainframes (which had no GUI but monolithic applications) we
have the concept of "user exits":
Specific actions like opening or storing or application-internal
transformations can be configured to be done by calling external programs. Easy
and effective – I know some really large applications (>500 developer years) in
a technically very challenging environment which even nowadays use this
intensively.
Shared storage is easy, too – be it common file formats (and some form of race
condition prevention), data bases or service like »akonadi« (a good idea
implemented l…ess than optimal …).
D-Bus is, IMHO, a very clever approach of IPC for GUI application, alas, not
very well accessible from scripting … but with a lot potential.
> …
> It's interesting to have your ideas - thank you. Even if some are out of
> scope for KAlarm's intended use, others do provide some ideas for future
> development.
I'm looking forward to these future developments.
--
You are receiving this mail because:
You are watching all bug changes.
