Date: Tue, 29 Mar 2011 18:11:28 +0400 From: Aleksey Cherepanov <aleksey.4erepanov@...il.com> To: john-users@...ts.openwall.com Subject: Re: Interface for John > We should be able to add advanced features once the basic functionality > is in place, but any advanced-only features should be in tabs, menus, or > whatever - not confusing new users. That said, just what advanced > features are you thinking of that would be confusing new users if not > "hidden"? I think features for new users may be also advanced. I mean extended userfriendliness like hints, tips and documentation integrated in the interface. Is that important? About confusing i think it is possible that users may be afraid when there are many options they do not need now. For instance, navigation and filters for the resulting table are necessary for all users but may confuse someone. I think in the simpliest way there should not be any options at all. But they should be easily accessible. I think users do three types of work: managing of files and their hashes, managing of settings and managing of Johns. Each type of work will have its own features not connected to other types of work. For instance user may want to look through hashes and split them by type without running John. I've already imagined an powerfull interface that will not confuse anyone. I will show it soon but whithout functionality. Managing of files consists of selecting a part of file, splitting files by different parameters like hash types, shells, or even by number of password with the same salt, joining files together. Managing of settings consists of setting up everything and making profiles with sets of configured options. Each started John have its own set of options. Managing of Johns consists of starting, stopping one or multiple Johns keeping sessions. For wrapper it is possible to run John remotely (for instance over ssh). It seems to be good for gui to have its own sessions and to be able to be setted up with John's session file. A question about reading John's output: is it needed to read John's output on the fly? Or is it possible not to read output and to call 'john --show' by user's demand? Or should it be customizable? If it is possible to read from time to time and not line by line as John writes then it should be easy to read input from csv as of WxWidgets supports csv reading through wxODBC module. It is interesting because it gives wxTable object that is capable to be used with customized wxGrid. It may provide an interesting property: all processor intensive operations would be done by WxWidgets. So using of wxPython should not decrease performance. Also wxPython is somewhat portable and it seems to be easy to distribute only a script while all distributions provide their own wxPython without any thoughts about binary compatibility. I do not keep python in my heart. I mean it is ok for me to write in C++ (or even with Qt; i like to learn anything new). But prototyping with python splits a task into two separated: writing a fully functional gui and integration of gui and John. I could imagine that writing of an excellent gui may spend a full summer. And a good pythonic gui even without next integration may be good in the whole. Also it is possible to make then a python (and others) bindings to John. Regards, Aleksey Cherepanov
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.