Date: Sun, 03 Apr 2011 00:11:15 +0300 From: Shinnok <admin@...nnok.com> To: Solar Designer <solar@...nwall.com> CC: john-dev@...ts.openwall.com Subject: Re: [GSOC] Another GUI idea for JTR :-) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again Alexander, I have written a basic concept GUI for JtR name Johnny and uploaded some screenshots to the wiki page: http://openwall.info/wiki/john/GUI#Shinnok . No interfacing to john is done. The GUI in the current state is a proof of concept and it doesn't implement everything that I am going to describe bellow, though it should be enough to prove the concepts and GUI paradigms that i've chosen. There's still lots of thinking to do, on issues like how to visually present multi-sessions and better grouping of options and actions in category tabs, as well as lots of work small or iterative tasks like tooltips, menus. I will e-mail again once I have considerable advancement with Johnny or built packages(static or not) for some of the platforms supported(currently you have to build Johnny yourself if you want to see it for real). What follows is an overall and future plan useful both now when I am trying to describe what Johnny is all about as well as for further reference. Next I am going to describe in more detail what I am thinking about and how would I see further implementation of Johnny. The reasoning behind the GUI is simple but at the same time profound: Complexity through simplicity and non-intrusive expert and non-expert availability. The idea is that with careful design and by identifying the most basic and common operations(or concepts) of JtR which we can then use as main actions within the application(the big intuitive buttons in Johnny) as well as action containers(the tabs in each session) grouping logically related actions for the more advanced(expert) options that JtR has available. This way we don't need to *hide* the expert options in complex menus and/or dialogs(+questions) that might popup at undesired moments in time(which btw, it is very hard to come with a timing that pleases for all) or be really annoying for the more experienced users(they'll perceive them as nag screens or a wall in their efficiency). With this design we hide the expert options in *plain sight*, thus making them ignorable for inexperienced users through default reasonable(and visible, not hidden in menus and such) options (restore:yes, allgroups, allshells, allusers, etc..) and at the same time accessible to the experienced ones with at most one click(or keyboard shortcut). Hover help tooltips for all options and actions achievable from the GUI are provided as well as a big help button, to encourage the unexperienced to dive into more advanced usage of john. The interface also leaves room for lots of new options, either future john options, as well as gui specific options like, hash detection, dictionary editing and generation or interactive bruteforce charsets or rules creation and many more cool things that I am thinking about. :-D The GUI also shows a possible approach to the millions of table(spreadsheet) rows issue raised by you Alexander when discussing the GUI. The approach consists of using a model view implementation using QAbstractTableView(http://doc.qt.nokia.com/latest/qtableview.html) and QAbstractTableModel(http://doc.qt.nokia.com/latest/qabstracttablemodel.html) which eliminates the need to have a widget for each single table cell(an approach which would render a system/application useless(both cpu and mem terms) at about 10000 widgets). The current model view allows for about 500000 items to be displayed in less or equal to a second(on my system),using reasonable amounts of ram and then scroll and interact with the items seamlessly and smooth. There's still room for improvement, for eg. to display handle the displaying itself manually too using QAbstractItemDelegate(http://doc.qt.nokia.com/latest/qabstractitemdelegate.html) and work with more raw data structures instead of Qt's ones(QString) as well as try to omit some additional steps when passing/modifying data from the controller to the custom data structures in the QAbstractTable model. The end goal is to print 1000000(one million) table lines in less or equal then a second, which is a comfortable number. One can test the loading of data in the current model-view implementation by pressing "Load 500000 hashes" in this screen http://openwall.info/wiki/_detail/people/shinnok/johnny/johnny-gnome-unity-1.png?id=john%3AGUI&cache=cache , if you built johnny that is. That's about it for now, I'm waiting for your feedback. Regards, Shinnok On 03/28/2011 08:28 PM, Solar Designer wrote: > Shinnok - > > On Sun, Mar 27, 2011 at 06:21:07PM +0300, Shinnok wrote: >> By reading the latest e-mails on john-dev and john-users >> as well as the ideas wiki page debating the GUI issues i >> would like to propose my own idea for a GUI to john as well >> as disseminate the views on Qt and why i would chose it. > ... > > Thank you for writing this! Unfortunately, I have difficulty finding > time to fully review and consider it now, but I intend to. I've also > referred to your posting in the thread on john-users such that others > making proposals for a JtR GUI can consider your thoughts on the matter. > > I also appreciate you posting a link to your proposal to Nmap. It is > helpful for us to know who intends to apply to other projects as well. > > I am leaving your message "flagged" in my mailbox as needing further > action on my part. > > Thanks again, > > Alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNl5DsAAoJEAzuYPBIYMpXGzQIAJEJEWlLsEwpatYvBHjmsOZ9 kF10/Rw0UUn6kgDBrCFdWurCpKyv5M3gNrageETDEXHgrwPHUNCXC67VnXWD5BKg VCuc1i8wXe/iuGVz/xrAXUUyHnZqJ7h3wEL27Ck18YXWfXjnNiMdaupIRIcJo6DI jaKWkoYXBalQVb6j5O6VFp0Komlgeqvxu21Lgmesd47cLB4f6Vs52WvsWF9g2B2j L0j0/F1KqrIvHVUDWNLkvM3dCLxBLQ3LJJEwEla9wI31RBjjskFg1PFI9mFS+ccr vdMSCyMxJDLqHwumwUfONz3p0Cti3mkHQtrOlGobe05QFx64mQOdxh8GkfqKUAo= =RM5a -----END PGP SIGNATURE-----
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.