Hoi Habi, On March 17, 2011 05:58:28 am David Haberthür wrote: > The applications for the OpenUsability Season is open until the end of > march. No others got back to this thread with suggestions and support. > This leaves me wondering if we should apply for a project there. As I > mentioned before, the OpenUsabilty application seems to be "easier"
It may be easier to apply, and maybe also to get accepted, but getting this right is a big one. There is a lot of critique of the Hugin UI, and most of it is deserved. But it also lacks the understanding of how we got here, what are the limitations, and what can be done about it. Start with the layout. Re-arranging the layout may seem to be one of those low hanging fruits, a quick and easy win. Every half-baked designer can produce a couple of improved drawings of the existing screens; and if they were to be implemented with a technique similar to CSS it could all be done in a matter of a weekend. Hugin depends on the wxWidgets GUI toolkit. Layouts are described in a cumbersome XML derivate called XRC for which I know of no good WYSIWIG editor. I have tried a few. It is not possible to simply put an element at position(x,y) of the page like with CSS on a web page. I am not aware of a good enough layout editor for wxWidgets. I have tried with the usual suspects and it is painful work. To make things more complicated, some parts of the layout are generated by the application, not in the XRC files. This makes them unaccessible to a designer, unless the designer also has coding skills to understand what happens in those parts of the code that deal with the drawing of the elements on the screen. Not only does Hugin depends on the wxWidgets GUI Toolkit, it also strives to be compatible with multiple platforms and multiple versions of wxWidgets. wxWidgets itself strives to support as many platforms as possible. This has advantages: define your GUI once and use it on all platforms. But it also has disadvantages. wxWidgets tries to use native controls when possible; and wxWidgets evolves, so things that are possible in 2.9 were not possible in 2.8. Hugin currently supports 2.7 and 2.8. Support for 2.9 is experimental. Many of the points raised against the Hugin GUI are actually "toolkit issues". For example sortable columns in a table - this is a functionality that should be provided by the GUI toolkit as it is generic enough to be of interest to many programs, not just to Hugin. Probably the current version of wxWidgets has it, and it is just a matter for somebody who is knowledgeable of the state of wxWidgets to go over Hugin and add the necessary flags to activate the functionality. But back then when the tables where first implemented in Hugin, wxWidgets was much less mature than today, and so there was a reason not to introduce sortable column (or maybe there was no such functionality at all), resulting in today's papercut. Many of the points raised against the Hugin GUI are indeed papeprcuts. Users and contributors learn to live with them and work around them over time, so that when they achieve the proficiency necessary to fix them, they are no longer motivated. Then there is the workflow. Hugin has grown historically as a GUI to access steps in a worklfow. Then the workflow has been expanded. Alternate workflows and uses have been introduced. Things have grown historically. It takes somebody who understand the workflow and use of Hugin to make deep and significant changes into its UI so that it still fits the way the current user base uses Hugin. Back in 2007 one of the first GSoC project was a GUI redesign. The result was a refactoring of the code, and an initial Qt GUI implementation. The refactoring has lived on, and indeed the Hugin code was in a much better state after that project. But one summer was not enough to do all what was planned, and so the Qt GUI implementation lingered, while new contributors added new functionality using the wxWidgets framework. And wxWidgets has improved over time, so that Qt GUI now lingers in a development branch that will probably have to be declared abandoned / obsolete at some point. I think that before applying to OpenUsability, we need a clear understanding of what are the skills and time required for such a work to become practical. Yuv
signature.asc
Description: This is a digitally signed message part.
