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

[Ippei UKAI]

Hello,

Thank you for taking your time:)

On 31 May 2005, at 20:25, douglas wilkins wrote:
> 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.

Now it looks much better. Yesterday, I wanted to get the newest  
source for new beta quickly and it made me blue when I saw the blue  
background on the window. The layout is still awkward on Mac, but now  
I can see where it goes and start thinking things constructively upon  
this new one.

>
>
>> 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.
>

Sorry, I didn't know that. I thought we are fixing the initial  
request about grouping.


> 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 prefer grouping with separators.
wxMac seems not handling font style very well (it's not displayed  
with system font if you specify a font, even with "default" family).  
I'd rather go for putting separators with static text label without  
anyspecific font. By the way, small font inserted between widgets  
does not look very well. They are like side notes rather than titles  
of each section.


>> 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.

If you are just fixing the bug, why does Stitcher panel have totally  
new looking?

>
>> 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.
>
>
>> 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 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.
>

  I thought changing the GUI style is huge change which is far bigger  
than changing some widgets' place a little or which class a function  
should belong to. Maybe I should stop thinking like a user, but still  
debugging 20 lines of new code may be easier than improving the all  
new style of GUI fit for all three platforms.


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

Changing whether some widgets are grouped/labelled or not is  
definitely far smaller than changing overall GUI style.


>> 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".
>

I now partially agree with this as the new design getting better  
faster than I thought. But, I would still say fixing awkward grouping  
of GUI is at least as easy as making new "spaces around groups"  
design fit on all three platforms.


>> 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.
>

I meant one for 0.5.0, which will be released soon and one for 0.5.1  
which will improve the GUI design before not too long.


>> - 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.
>

I think it is more space effective if we use horizontal sizer on top;  
the table and x,y,x,y,mode part in left and rest in right; because I  
always see empty space inside the table. And now the right-hand side  
is the controls for the editor above, which do not need to be inside  
the group.


>> - 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.
>

I think Optimizer and Stitcher has the same principle. The users only  
touch top part unless using custom setting which involves setting  
parameters shown in the bottom part. The thing is Stitcher has FOV  
and Projection, that are not custom settings. So, I put those on the  
left half of the top part. Users set FOV and Projection comparing  
with preview window, then decide the format and get the image. It  
perfectly follows the typical flaw. As to the specific layout on the  
mockup, it is following the existing style which you are eventually  
improving.


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

Yes, I'd like to hear from others about this too.

Cheers,
Ippei

-- 
  ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>>
   My general MSN, AIM, and E-Mail: ippei_ukai at mac.com
   Homepage:  http://homepage.mac.com/ippei_ukai/