CLI is faster than GUI myths

"Daniel Hiepler" <rigid@boogiepalace.hopto.org> wrote in message

news:20111112015835.152a14e2@boogiepalace.nifty.lan...

Vom: Fri, 11 Nov 2011 10:59:31 +0100

 

Hi,

 

>> Id like to start this thread to address the "CLI is faster than GUI"

>> myths. I challenge diehard CLI users to add their favorite command

>> that they think cant be done as efficient in a GUI, and I'll try to

>> find a equally efficient way to do it the GUI way.

>>

>

My challenge would still be the same as mentioned in the earlier thread:

 

Take a large circuit with say, 500+ different signals. You got a "bus"

of different signals, say OUT[0..255] and DATA[0..511].

They are aligned in a complex way, so you can't select more than one

signal with one click. Now you want to rip them up (and only them).

I think the most efficient way would be "ripup OUT* DATA*;"

This would (again) be handeled with a filter selection tool. You would find

it in the menu (also with a hotkey, as most often used menuitems has) and

you enter a regexp to select the nets you want to work on. Then you select

ripup. In theory it will take one hotkey press + enter the "OUT* DATA*"

string, enter key and select the ripup tool in the menu (I dont think a

shortcut to ripup is wanted, because you may want some threshold on

destructive tools).

Another challenge, apart from eagle, is this (not really serious):

 

Receive an 8-bit digit X via UDP port 1000 and then draw a filled black

circle with 50 pixel radius on position 5/15 into 3

imagefiles /tmp/image[X].jpg, /tmp/image[X+1].png

and /tmp/image[X+2].gif overlaying the previous image-content.

I guess you want to do this in a ULP? I can't see how a direct CLI command

could do this (the X+n insertion), but it may be something Ive never had any

use for.

The ULP (same or different language, like TCL) must never be removed, so a

proper GUI is orthogonal to this problem.

I'd also like to see ULP also being able to create new root projects and

have write access to them direct instead of through scripts. I'd also like

to have event triggered ULP's.

I guess also tools like Altium also has a programming language, but its

rather poor documented.

Please don't nail me on this one, it's just an extreme example of

an extraordinary special usecase where you have no chance with any GUI

while you can do it extremly easy and quick with one line in a

CLI/shell. (If you know how and don't have to learn everything

first.)

It becomes more obvious when a task must be repeated

oftenly. With a CLI you can just press <cursor-up> to redo (or

copy/paste at least with any CLI). It has been mentioned that you can

also assign a shortcut-key.

Like what task? If you need to redo your command often like that, you've

done some wrong thinking in the first place..

You may have a small point if you alternate with some other command, and

click up twice, but I challenge you to give me some real examples, and I'll

tell you how it should be done.

Additionaly, eagle does it better than you: If you click-select you

could easily miss a signal/part. If you say "LED*" then it really means

every LED(...)-signal. So please don't see the CLI only as interface

alternative, but also as a general principle of designing (which would

prevent errors in this case). The best CLI is useless if your design

is bad. For example, your naming doesn't make sense or your design is

generally chaotic/unstructred.

I think I lost your point in this paragraph. Please specify if its not

covered with the filter select tool.

>> A proper GUI would let you select the components you want to change

>> with either a select window drag (not having to activate the group)

>> like a powerpoint presentation design. It will also let you add and

>> remove using ctrl (or shift) selects like you do in a (win)

 

...or you can use a lasso-tool or "select-by-layer" etc. You could even

have a mixture between GUI and CLI by providing sort of a tree-view of

you whole project, showing all objects (signals, parts etc.) to

perform different actions on (like scene-graphs known from 3D CGI

Software).

Yes, lasso-tool is probably the right name for the standard GUI area select

tool. A tree view of components would probably be good. Not sure if a tree

view of nets will, but maybe of classes.

>> filebrowser. Also, a filter selection tool could help you add

>> component based on name or other parameters.

 

Yes. A filter would be a small LI inside a select-tool. This could

support wildcards, patterns or even interpret regular-expressions.

 

>

Generally, all you can answer to different challenges is inventing

different GUI features that solve that challenge (more or less

efficient).

What you forget is, that someone has to implement that GUI feature

(write code) and a decision must be made on how to implement it (GUI

design).

 

Excellent GUI design is far from beeing an easy task (obviously).

In fact I have seen stuffed & un-intuitive GUIs that were so

feature-rich trying to cover every possible use-case, that in the end

they were almost unusable - although the underlying software was

excellent (which was practically the only reason why someone decided to

buy the software in the first place).

It needs some upfront planning for sure, but you get a lot for free if

programmed right. But I do see the cross platform support as a challenge

when using os specific functions to support it.

Apart from the fact that designing a GUI is a never-ending task (since

new features, that need a new kind of GUI interface, are added

constantly) it is often overseen that a CLI is just a formal and

structured representation of the programs' functionality.

If its a never ending task, it has not been properly planned. Even CLI's can

(should!) develop. Ive seen a few examples where current Eagle CLI doesnt do

the job and has to be tweaked with certain SET extensions. Look at some

requesters with several choises, like when trying to merge nets. CLI can't

handle it (although it could with some extensions).

The programmer writes one piece of software (the parser) once. He never

has to touch it again. It's finished. (Which is generally a good thing

since no new bugs arise). New features don't need new parser code.

That is not true. Every parser needs to develop. Now with v6, it has to

support new commands, and there will be cross dependancy wich it needs to

handle.

This not only prevents bugs, but enables developers to quickly enhance

functionality by extending the parser.

Say for example the parser can parse something like "<command>

<argument>".

Then you can extend it to understand list of arguments "<command>

<arg1> <arg2> ...". After that, you implement wildcards or regular

expressions etcetc.

I don't get it. Why is that harder to do on the GUI?

All those changes affect all possible commands (i.e. the whole

functionality). The reasonable maximum amount of parser-features is

limited, so that the parser-code is finished at some point, no matter

how complex the parser is.

The risk does not lie in the parser (or the GUI handler, its part of the

OS). Its in the functions beneath it.

I hope the advantage from the software-designers' & developers' point of

view becomes clear. Additionally it's important to know that, if the

software-design is good for developers the users directly profit from

this in the form of less bugs, quick releases, more new features etc.

I think you are on the wong track.

But that's all theory. In reality your GUI must be "reasonable complete"

to solve the most common tasks quickly since the majority of (new) users

didn't (yet) learn the "structure" of the program or looked up CLI

commands.

Of course a new GUI would have to be complete. Eagle is not that far from it

really.

Also, in reality new features always mean new GUI elements (CLI support

or not). You still can run into the risk of an inefficient GUI. That is

what somehow happened to Eagle. Additionally it can happen that the

whole GUI must be completly re-designed at some point, forcing users to

regain already learned knowledge.

Current GUI is inefficient? I dont think so. It just lacks some functions

and the de-facto standard adoptions.

I think the whole point of the discussion is, that CLIs and GUIs are

not opposing paradigms. Instead it's just 2 layers sitting ontop of the

functions a software provides.

Nobody denied that. Its just that the GUI still has some proprietary issues

and some functions is missing.

So I really believe the one doesn't hurt the other but by providing an

alternative to the GUI (be it ULP, Rexx, LUA, CLI, whatever...) a

software can really unleash all its power in even the worst scenarios.

Thusly more users are kept from getting frustrated since, in the worst

scenario, you normally call for support. And it's better to get a

10-page-instruction list that solves the problem than hearing "This

just can't be done."

Now you're talking programming languages. That is also orthogonal to the

GUI.

And now for the sad part:

In theory every software would be fine with a minimal, well designed

GUI not implementing every feature but only the ones, you don't have a

CLI alternative for (like visualization, mouse usage, etc.)

So the GUI code would be finished at some point. Everything else would

be controlled by CLI and the GUI code doesn't need to be touched when

new features are implemented.

This is of course a developers' dream and it pretty much was the way

good software was designed decades ago. But times change I guess the

last CLI widely used by mainstream-users was the Hayes (AT) commandset

for dialup-modems (using a terminal program as GUI frontend).

So back in the days, users had to learn how to use a CLI but nowadays

it's quite uncommon among most users. And since a CLI doesn't have a

very steep learning-curve, lots of users try to avoid it wherever they

can, thus never have the pleasure of advanced CLI features.

 

This doesn't apply to Eagle alone but to most application-software and

operating systems in general.

All your thought was a bit disordered, I hope the reply is satisfactory.

Please post one thought at a time

Am 12.11.2011 21:21, schrieb Tilmann Reh:

Dietmar Schwertberger schrieb:

>> While we're at that:

>> I want to manually re-number my components by clicking one component

>> after the other.

>> The current Eagle GUI does not support me much:

>> If I want to name anything "R1", then I have to ensure first that no

>> other component is named "R1".

>> Then, when moving on to the next, I have to enter "R2".

>> The result is that I don't clean up my component numbering....

>>

>> Is there a solution involving the CLI or a ULP?

 

Maybe - I was already thinking about writing such a ULP (time permitted,

and besides I fear that a ULP can't accept mouse clicks at all...).

Sounds good as temporary solution.

But I assume that most users would not use/find it if the functionality

is not included into the GUI.

I would expect something like that in the Name dialog box:

  - "Auto increase" checkbox

  - "Resolve collisions" radio group or choice

    ("Inhibit", "Skip", "Rename other")

Maybe a context sensitive toolbar could indicate whether the next number

is available (green) or not (red).

Maybe the two features could be integrated into the context sensitive

toolbar.

I was asking for a CLI solution as I seem to remember that there is one

command which supports automatic numbering, but only in the CLI.

For the time being, I use renumber-sch-group.ulp - if you first renumber

to a rather high starting index, you at least don't have any collisions

at the lower when doing the final manual renumber.

As cleaning up is only 'nice to have' for my PCBs, that's already more

work than I wanted to invest...

Regards,

Dietmar

I wrote:

>> While we're at that:

>> I want to manually re-number my components by clicking one component

>> after the other.

>> The current Eagle GUI does not support me much:

>> If I want to name anything "R1", then I have to ensure first that no

>> other component is named "R1".

>> Then, when moving on to the next, I have to enter "R2".

>> The result is that I don't clean up my component numbering....

>>

>> Is there a solution involving the CLI or a ULP?

 

Maybe - I was already thinking about writing such a ULP (time permitted,

and besides I fear that a ULP can't accept mouse clicks at all...).

After thinking a short time about this, I posted a suggestion in a

separate thread.

Tilmann

Dietmar Schwertberger schrieb:

While we're at that:

I want to manually re-number my components by clicking one component

after the other.

The current Eagle GUI does not support me much:

If I want to name anything "R1", then I have to ensure first that no

other component is named "R1".

Then, when moving on to the next, I have to enter "R2".

The result is that I don't clean up my component numbering....

 

Is there a solution involving the CLI or a ULP?

Maybe - I was already thinking about writing such a ULP (time permitted,

and besides I fear that a ULP can't accept mouse clicks at all...).

For the time being, I use renumber-sch-group.ulp - if you first renumber

to a rather high starting index, you at least don't have any collisions

at the lower when doing the final manual renumber.

Besides, using the group functionality (rectangle area sorting), you can

minimize the manual interactions to some degree.

Tilmann

Am 12.11.2011 01:58, schrieb Daniel Hiepler:

Take a large circuit with say, 500+ different signals. You got a "bus"

of different signals, say OUT[0..255] and DATA[0..511].

They are aligned in a complex way, so you can't select more than one

signal with one click. Now you want to rip them up (and only them).

I think the most efficient way would be "ripup OUT* DATA*;"

Would be solved by the filter tool described below.

It becomes more obvious when a task must be repeated

oftenly. With a CLI you can just press<cursor-up>  to redo (or

copy/paste at least with any CLI). It has been mentioned that you can

also assign a shortcut-key.

Many GUI tools have macro-recorders. Depending on the archictecture

of an application, it's either easy to implement or unrealistic...

Additionaly, eagle does it better than you: If you click-select you

could easily miss a signal/part. If you say "LED*" then it really means

every LED(...)-signal. So please don't see the CLI only as interface

alternative, but also as a general principle of designing (which would

prevent errors in this case). The best CLI is useless if your design

is bad. For example, your naming doesn't make sense or your design is

generally chaotic/unstructred.

While we're at that:

I want to manually re-number my components by clicking one component

after the other.

The current Eagle GUI does not support me much:

If I want to name anything "R1", then I have to ensure first that no

other component is named "R1".

Then, when moving on to the next, I have to enter "R2".

The result is that I don't clean up my component numbering....

Is there a solution involving the CLI or a ULP?

I see this thread also as CLI cookbook for the GUI users.

But still, for such a standard task, no CLI should be required and

I would expect the dialog box to have two checkboxes for what I want

to accomplish.

...or you can use a lasso-tool or "select-by-layer" etc. You could even

have a mixture between GUI and CLI by providing sort of a tree-view of

you whole project, showing all objects (signals, parts etc.) to

perform different actions on (like scene-graphs known from 3D CGI

Software).

Yes. A filter would be a small LI inside a select-tool. This could

support wildcards, patterns or even interpret regular-expressions.

+1 for tree and filter and also the rest of your post...

Regards,

Dietmar

Am 12.11.2011 00:56, schrieb Daniel Hiepler:

I think this is exactly the wrong way, since good software shines most,

when it can solve your very specific and uncommon problem in an

efficient and painless way, better than competing software products.

(It's useless if the software can do a thousand things but can't do

what you want right now. Or need very much effort to do it)

Usually, when I write software or our department has to solve problems,

we take the pareto approach: what are the most common problems?

Once these are addressed, we can move forward to the specific problems.

Of course, it should do that for a maximum amount of different users.

(It's useless if it can solve very specific problems for only 1% of the

userbase)

That's more in the spirit of the pareto approach.

I made good experience with

  - providing standard GUI solutions for the common problems

  - provide examples / a cookbook how to solve the specific problems

    with CLI; even non-programmers manage to adapt these to their tasks

But, over time, more and more tasks are moved from the CLI to the GUI.

I admit that for many of my tasks a good GUI is much more work than

the logic behind.

Also, it's not possible to define a good GUI on paper and then just

implement it. It always requires some iterations. Sometimes it takes

me years to have a good idea for a certain task.

Regards,

Dietmar

>Are you answering with how to do a task with an ideal GUI or with EAGLE 5

as it stands today? If it's the first one (ideal GUI) then it's a useless

exercise as that GUI doesn't exist. Of course the perfect GUI would work

perfectly. But that's not very useful.

This addresses how a GUI should be in a near ideal case, and how non-Eagle

GUI standardards would handle it.

Vom: Fri, 11 Nov 2011 10:59:31 +0100

Hi,

Id like to start this thread to address the "CLI is faster than GUI"

myths. I challenge diehard CLI users to add their favorite command

that they think cant be done as efficient in a GUI, and I'll try to

find a equally efficient way to do it the GUI way.

 

My challenge would still be the same as mentioned in the earlier thread:

Take a large circuit with say, 500+ different signals. You got a "bus"

of different signals, say OUT[0..255] and DATA[0..511].

They are aligned in a complex way, so you can't select more than one

signal with one click. Now you want to rip them up (and only them).

I think the most efficient way would be "ripup OUT* DATA*;"

Another challenge, apart from eagle, is this (not really serious):

Receive an 8-bit digit X via UDP port 1000 and then draw a filled black

circle with 50 pixel radius on position 5/15 into 3

imagefiles /tmp/image[X].jpg, /tmp/image[X+1].png

and /tmp/image[X+2].gif overlaying the previous image-content.

Please don't nail me on this one, it's just an extreme example of

an extraordinary special usecase where you have no chance with any GUI

while you can do it extremly easy and quick with one line in a

CLI/shell. (If you know how and don't have to learn everything

first.)

It becomes more obvious when a task must be repeated

oftenly. With a CLI you can just press <cursor-up> to redo (or

copy/paste at least with any CLI). It has been mentioned that you can

also assign a shortcut-key.

Additionaly, eagle does it better than you: If you click-select you

could easily miss a signal/part. If you say "LED*" then it really means

every LED(...)-signal. So please don't see the CLI only as interface

alternative, but also as a general principle of designing (which would

prevent errors in this case). The best CLI is useless if your design

is bad. For example, your naming doesn't make sense or your design is

generally chaotic/unstructred.

A proper GUI would let you select the components you want to change

with either a select window drag (not having to activate the group)

like a powerpoint presentation design. It will also let you add and

remove using ctrl (or shift) selects like you do in a (win)

...or you can use a lasso-tool or "select-by-layer" etc. You could even

have a mixture between GUI and CLI by providing sort of a tree-view of

you whole project, showing all objects (signals, parts etc.) to

perform different actions on (like scene-graphs known from 3D CGI

Software).

filebrowser. Also, a filter selection tool could help you add

component based on name or other parameters.

Yes. A filter would be a small LI inside a select-tool. This could

support wildcards, patterns or even interpret regular-expressions.

Generally, all you can answer to different challenges is inventing

different GUI features that solve that challenge (more or less

efficient).

What you forget is, that someone has to implement that GUI feature

(write code) and a decision must be made on how to implement it (GUI

design).

Excellent GUI design is far from beeing an easy task (obviously).

In fact I have seen stuffed & un-intuitive GUIs that were so

feature-rich trying to cover every possible use-case, that in the end

they were almost unusable - although the underlying software was

excellent (which was practically the only reason why someone decided to

buy the software in the first place).

Apart from the fact that designing a GUI is a never-ending task (since

new features, that need a new kind of GUI interface, are added

constantly) it is often overseen that a CLI is just a formal and

structured representation of the programs' functionality.

The programmer writes one piece of software (the parser) once. He never

has to touch it again. It's finished. (Which is generally a good thing

since no new bugs arise). New features don't need new parser code.

This not only prevents bugs, but enables developers to quickly enhance

functionality by extending the parser.

Say for example the parser can parse something like " ...". After that, you implement wildcards or regular

expressions etcetc.

All those changes affect all possible commands (i.e. the whole

functionality). The reasonable maximum amount of parser-features is

limited, so that the parser-code is finished at some point, no matter

how complex the parser is.

I hope the advantage from the software-designers' & developers' point of

view becomes clear. Additionally it's important to know that, if the

software-design is good for developers the users directly profit from

this in the form of less bugs, quick releases, more new features etc.

But that's all theory. In reality your GUI must be "reasonable complete"

to solve the most common tasks quickly since the majority of (new) users

didn't (yet) learn the "structure" of the program or looked up CLI

commands.

Also, in reality new features always mean new GUI elements (CLI support

or not). You still can run into the risk of an inefficient GUI. That is

what somehow happened to Eagle. Additionally it can happen that the

whole GUI must be completly re-designed at some point, forcing users to

regain already learned knowledge.

I think the whole point of the discussion is, that CLIs and GUIs are

not opposing paradigms. Instead it's just 2 layers sitting ontop of the

functions a software provides.

So I really believe the one doesn't hurt the other but by providing an

alternative to the GUI (be it ULP, Rexx, LUA, CLI, whatever...) a

software can really unleash all its power in even the worst scenarios.

Thusly more users are kept from getting frustrated since, in the worst

scenario, you normally call for support. And it's better to get a

10-page-instruction list that solves the problem than hearing "This

just can't be done."

And now for the sad part:

In theory every software would be fine with a minimal, well designed

GUI not implementing every feature but only the ones, you don't have a

CLI alternative for (like visualization, mouse usage, etc.)

So the GUI code would be finished at some point. Everything else would

be controlled by CLI and the GUI code doesn't need to be touched when

new features are implemented.

This is of course a developers' dream and it pretty much was the way

good software was designed decades ago. But times change I guess the

last CLI widely used by mainstream-users was the Hayes (AT) commandset

for dialup-modems (using a terminal program as GUI frontend).

So back in the days, users had to learn how to use a CLI but nowadays

it's quite uncommon among most users. And since a CLI doesn't have a

very steep learning-curve, lots of users try to avoid it wherever they

can, thus never have the pleasure of advanced CLI features.

This doesn't apply to Eagle alone but to most application-software and

operating systems in general.

many regards

James Morrison wrote:

 

Good idea I think.  This could actually be educational to people on

both sides.

 

Scenario 1:  Move PCB elements (components, traces, vias, ...) by some

exact, very small amount, say 0.001mm.  I don't think that is even

possible with GUI since the grid won't display.  You could argue

then, why does it matter to move such a small amount, but I like to

be accurate

 

>

Dietmar wrote

A third alterntive may be to use the arrow keys.

I used to have a drawing program where you could move and place by pixel

using the arrows.

In Eagle, this could e.g. move by a grid size. Pressing Alt+Arrow would

move by the alternative grid size.

Pressing Shift-Arrow would move by a multiple of the grid.

Pressing Ctrl+Arrow would snap to grid (just as now with MOVE and Ctrl).

Pressing CtrlAltArrow would snap to the alternative grid.

To assist the user, the properties dialog box may display some info

about how to move using the arrow keys.

My reply

I would like to be able to "nudge" objects into place with the arrow keys as

dropping with a mouse is inaccurate and the grid may be inappropriate.

It cannot be a pixel by pixel event as with drawing programmes as that is

not relevant to CAD as we need to be in control of a measured distance.

An arrangement that may work is a dialog/control that is a slider/spinner

that displays the distance a nudge will cause. It is displayed when you

select 'nudge'.  This you slide/spin with the mouse and it shows the nudge

distance as well while you are nudging so you can nudge coarse and then

finer. The control stays on top or more likely on a tool bar .

The slider/spinner would best be a  list of pre-SET nudges that you set up.

As you enter nudge mode for the current selection, a measure is reset.

Concurrently displayed is the total XY shift since beginning the nudge. This

would be useful for when you have predetermined the move distance and

enables you to monitor it to completion.

Warren

--

Viewed / responded via the newsgroup at

news.cadsoft.de

Vom: Fri, 11 Nov 2011 17:11:27 GMT

I think only realistic, practical cases should be taken seriously.

Commands/procedures that either are useless or very seldom performed

should not be submitted.

 

I think this is exactly the wrong way, since good software shines most,

when it can solve your very specific and uncommon problem in an

efficient and painless way, better than competing software products.

(It's useless if the software can do a thousand things but can't do

what you want right now. Or need very much effort to do it)

Of course, it should do that for a maximum amount of different users.

(It's useless if it can solve very specific problems for only 1% of the

userbase)

best regards