Re[2]: Nmap GUI

[digmet <digmet () mail ru>]

Hello, Fyodor.

Monday, June 6, 2005, 12:34:28 AM, you wrote:
F> The goal of a new GUI, IMHO, is not just to help the newbies and
F> casual users who have trouble remembering Nmap's (literally) hundreds
F> of command-line options.  NmapFE already does a decent job of that.  I
F> believe a graphical interface can be extremely powerful in a different
F> way than command-line.

0. Completely agree.

F> Here are some ideas and questions.  I would be interested in hearing
F> other users' input:

F> o Portability - I believe that the frontend should work on UNIX,
F>                 Windows, and MAC OS X.  I just don't think we have the
F>                 resources to maintain multiple top-notch GUIs.  I
F>                 believe that a Windows GUI is especially important
F>                 because cmd.exe just sucks.  I use bash on Cygwin
F>                 instead, but it is still hobbled by Windows
F>                 limitations.

1. Agree. Windows GUI is very important. Cmd.exe sucks.

F> o Machine code or interpreter?  People have applied to do the new
F>   GUI in C/C++ with various libraries (Qt, GTK2, etc.), Java, Python,
F>   and even .Net/Mono.  I tend to favor C/C++ because the distributed
F>   application wouldn't require users to download a large interpreter.
F>   But perhaps some interpreters (Python?) may be small enough to
F>   distribute in the installer.
2. I think: we should use only one language in whole project. C/C++.
Libraries: Qt or GTK ?
I think: we should use Qt. Because it
2.1. more powerful and flexible. (IMHO).
2.2. realy good work in windows.
2.3. Eye candy.

F> o Installer -- Supporting an executable installer on Windows sounds
F>   like a good idea to me.  Windows users seem to expect that.

3. Yep! First of all! Very nessary for windows users.
At present they have to install several separate products manually
(from several URL), reboot system during installation, make changes in
registry...
It should be one install package.

F> o Nmap XML Output -- The GUI should read at least this format, IMHO,
F>   and possibly others.  The GUI should offer to run Nmap for you
F>   (supporting all of the major options in a well-organized serious of
F>   tabs/dialogs), or allow you to simply import your own results.
4. I think: GUI should cover all functions. (m.b. in next version).

F> o Searching, sorting, and drilling-down into results.  It
F>   would sort of features people would value here.  Maybe I should
F>   solicit mock-ups from the applicants to see what they have in mind.
F>   Or maybe provide a list of tasks that should be made easy ("Find all
F>   systems running OpenSSH", "Find all systems with port 80 open",
F>   "Find all Solaris boxes", etc.)  Anyone want to take a stab at such
F>   a list?
5.0. In my opinion exist 2 cases:
5.1. List of most useful (by statistic) use cases. If this list
packed, it's wait for implementation. I think that is simlpe than next
case.
5.2. Query language. Very flexible. Allow users to develop all they
wants. (In ideal like crystal reports).
Very big, complicate project. Comparable to whole current nmap.


F> o Comparing results.  An option to show the differences between last
F>   weeks scan and the one I did today would be quite valuable.
6. Very useful.

F> o Eye candy -- One (potential) advantage of a GUI is that it can
F>   support pretty pictures and icons.  I'm not talking about going
F>   overboard with dancing pigs here, but unobtrusive icons can be
F>   helpful.  For example, the host list could have icons next to the
F>   host name with a linux penguin, BSD daemon, or other
F>   platform-specific icon.  Perhaps even the services could be
F>   deliniated in a similar way so that you easily recognize (say) ssh
F>   daemons or mail servers in the results.
7. Unobtrusive icons must be customizable because of user model
difference in different OS.
M.b. simple ./skins/someskin.zip/icon???.bmp

8. Eye candy is very useful in results comparision.

F> o Extensible -- the interface must be designed so that it leaves room
F>   for growing new features later.
9.0. Yes.
9.1. All actions implement as command (design pattern "command").
9.2. Plugins
9.3. Flexible skins.

F> Also, what graphical libraries (or scripting interpreters, i suppose)
F> do you guys like?  Anyone have examples of good cross-platform open
F>  source GUIs we can use as a model to look at what they did right?
10. Qt.
Product: PSI.
http://psi.affinix.com/?page=about

Realy good cross-platform open source product.

-- 
Best regards,
 Andrey Anufriev              mailto:digmet () mail ru



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