Re: Zenmap usability upgrade: command line modification

[David Fifield <david () bamsoftware com>]

On Tue, May 27, 2008 at 12:59:08AM -0400, Jurand Nogiec wrote:
> This modification handles the problem where if a user modifies the
> command entry field, Zenmap does not necessarily execute this command
> and instead it will follow what the Target/Entry fields specify
> instead. This can lead to unpredictable results for the end-user,
> which must be avoided. This avoids a bug where if you edited a
> command, then selected a different target, the edited command line
> would be replaced with one from the currently selected profile.
>
> The command line field now reflects actual command was run instead of
> currently selected profile's options.
>
> When user starts to edit the command line field, the Profile and Entry
> fields are blanked out and therefore not used. This is an effective
> fix because then a profile is simply not used, and instead it is a
> "custom" entered command.

This is good. Now when you start to type in a command Zenmap assumes you
know what you are doing and deselects any profile. If you decide later
that you want to use a profile, only then does it erase what you've
typed and replace it with the command from the profile.

This was the biggest irritation about Zenmap's command line for me, that
sometimes it would rewrite my command without warning. However, there is
still something weird about this new solution, which is that when you're
editing a "custom" command line (one not associated with a profile), the
target entry is still active but typing something into it has no effect.
Also, if you type in a command, then select a profile, there's no way to
get your typed command back short of typing it in again.

I have this proposed solution, which may better reveal what's going on
in the user interface. It has two parts: what happens to the target
entry and what happens to the profile entry when a command line is
edited.

When you begin to edit a command, the target entry goes blank and
becomes inactive (grayed out) to indicate that the target comes from the
command line only, not the target entry. When you select a real profile
again the target entry would become active again.

(This idea for the target entry is a workaround for the fact that Zenmap
can't extract the target from an arbitrary command line. To do so, I
believe, would require an Nmap command line parser inside Zenmap, which
may be worthwhile because it would bring other benefits.)

As for the profile entry, when you start typing a command, the profile
entry would not go blank but would instead show something like
"<Custom>" to indicate that no profile is being used. Note that
"<Custom>" is not a profile, it's just a marker that means "no profile."
It should be rendered in a different font or color to indicate that it
is different. However it will be selectable in the profile selection
list; selecting it will use the current "custom" command. Whenever a
command line is edited, it becomes the new custom command.

Thus you would have the following commands at your disposal: all the
profiles, plus one custom command not associated with a profile. Editing
a command would switch you to "<Custom>". You could then select a
profile, then change your mind and your typed command would still be in
"<Custom>". Selecting a profile, then editing the command line would
both switch you to "<Custom>" and use the command you're editing as the
custom command, replacing any previous contents.

The differences in the profile entry from what exists currently are just
these:
  1. The entry shows "<Custom>" instead of blank for no profile, and
  2. The "<Custom>" option is selectable (you can't currently select the
     "blank" profile).

David Fifield

P.S. For my thoughts on how the Zenmap command line and profiles should
work, and why a command line parse may be a good idea, see
http://www.bamsoftware.com/wiki/Nmap/ZenmapCommandLine.

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org