New XRC files for Stitcher Panel (Was: Re: [ptx] thoughts for hugin UI, post 0.5)

[douglas wilkins]

Hi there,
I apologise in advance for the length of this response, but there are a lot of
points to be covered :-)

--- Ippei UKAI <ippei_ukai at mac.com> wrote:

> Can I make a suggestion?
> 
> I have just checked out the CVS and realised the xrc file is already  
> committed thus making HuginOSX GUI awful... 

I'm not sure why it now looks awful... more on this later.

> Looking at the xrc  
> source, I realised this is a huge change. Too big before 0.5. Even  
> after once looked ok with GTK, we need to make sure with MSW, and  
> then Mac. It takes ages.

It is a big change, but _only_ to the xrc and it was not a decision I took
lightly. The issue is this:
On both wxGTK and wxMSW wxStaticBoxSizers have a bug in scrolled windows. They
are not redrawn properly when scrolling. This leaves really ugly artifacts all
over the place which eventually obscure the data entry fields. This is
unacceptable. 

I could have pulled the scrolling code, but that would mean that not all of the
lens control panel could have been seen and the optimizer panel could not be
used in custom mode to adjust any image after the 8th image.

After looking at the ui guidelines that you pointed out, I judged that the
change to the layout still fell within those guidelines, specifically the
"Grouping with spaces" option displayed in Figures 15-20 and 15-21. In fact the
only platform that the layout feels a bit odd on is Windows, and even there it
is still acceptable.

I have tested the layout of all panels extensively on both wxGTK and wsMSW and
the only real issue I have with it has been pointed out, namely the Stitch
button being too far away from the rest of the controls on the stitcher panel.
That is something I still want to resolve, and I may well land up putting the
button back at the top.

These changes have been made with no changes to the code or to the labels and
therefore the translations. They are the minimum changes consistent with fixing
the original problem.

I do want to ask: When you say they look awful, do you have any specific
objections?

> 
> Why can't we divide the tree and work on the big change for xrc files  
> towards 0.5.1 or so?
> 0.5 was almost there. We could make small changes in how they are  
> grouped, but nothing more.

I would agree 100% if it were not for the redraw bug. I am a firm believer in
making _only_ bug fixes and _only_ the minimum change required when any
software approaches a milestone release. It is the only way to acheive
stabilty. After the milestone release, new features should be put in as soon as
possible to allow maximum time to stabilize any issues.

> 
> Here is a mock up that goes well with the current interface. (This is  
> a mock up, but simulating wx's sizer layout rather than osx's HI  
> guidelines. Group names are not really aculate anymore; we should  
> change them if possible.)
> http://homepage.mac.com/ippei_ukai/.Public/ 
> huginTemporaryDesignFor05Release.jpg

This layout is actually not possible with the current code-base. The
"interpolator" option _has_ to be grouped with the other stitcher engine
options. Any other layout requires changes to the code and this close to
release is not a viable option.

> 
> We can make this kind of change to conother panels as well. For 0.5,  
> we should concentrate on improving existing basis, not creating all  
> new shiny(?) interface. 

This is not (I believe) a new interface, merely a replacement of "lines around
groups" with "spaces around groups".

> It is easier for all if we design new things  
> in a different source tree and goal from 0.5 (If we do not make big  
> change in the actual source, then it's not hard to merge them  
> afterwards anyway.)

Post 0.5 there will be a lot of changes I'm sure, and I would like to establish
a stable and experimental branch in CVS so that we can experiment with some big
changes and then merge into the stable branch for the next release.

> 
> Here is a set of suggestions which should be easy enough for soon to  
> be released 0.5, but still addresses the confusing grouping issue.
> 
> - In Camera and Lens, stop grouping everything into the group called  
> Camera and Lens Information. (Unnecessary.)

True, but I wanted to make only the minimum change required to fix the bug, and
not change the interface.

> - In Control Points tab, put Zoom, Fine-tune button, three auto-  
> checkboxes, and add button out of Control points group. (Just making  
> the group smaller leaving controls concerning the above editor area  
> not grouped.)

I'm not sure what you are trying to say here.

> - In Optimization panel, stop grouping the Quick Optimizer group.   
> (Unnecessary; non-"quick" custom optimization stays inside the  
> "quick" group.)

Again, minimum changes only.

> - In Stitcher panel, interpolator should be outside nona and  
> PTStitcher panels. They both have the identical implementation. This  
> involves changing the source code, but it seems the concerning  
> function do not use any private variables of those panels.

See my comments above regarding code changes.

> - See the above mock up for my suggestion for Stitcher panel.

This we can discuss at length :-) 
I like the better use of space but not neccesarily the workflow implied by the
layout and the prominance of various controls.

Comments anyone?
As usual I am open to suggestions for a better solution :-)))

regards,
Doug




		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com