Issues with DateChooser look and feel when upgrading smartgwt

[mathias]

Hi dudes and dudarinas,

I upgraded smartgwtpro from 13.0-p20220208 to 13.0-p20220329, and got some layout issues.

FIRST ISSUE:
I made a small testcase:

public void onModuleLoad() {
        DateChooser chooser = new DateChooser();
        chooser.setShowTodayButton(false);
        chooser.setShowFiscalYearChooser(false);
        VLayout layout = new VLayout();

        layout.addMember(chooser);
        layout.draw();
    }

Now please consider these three images. They are in turn
1. smartgwtpro 20220208 running with tahoe skin from that build.

2. smartgwtpro 20220329 running with tahoe skin from 20220208

3. smartgwtpro 20220329 running with tahoe skin from that build.



As you can see they look a bit different, and in the last example the datechooser suddenly starts taking the entire layout, something which i don't think has ever been the case for as long as i've used smartgwt.


So a couple of comments/questions

a) it seems that chooser.setShowTodayButton works in 0212 but has stopped working in latest build.
b) it seems that chooser.setShowFiscalYearChooser doesn't work at all.
c) i feel that the behavioural changes of the layout is kind of significant. Isn't this a bit much within the same point release? (13.0)


SECOND ISSUE:
This is what caused this investigation:
I'm also having some issues with my custom skin which i've based on 0212. The datechooser looks pretty strange for us when we run our skin with 0329. Here are two "before and after" images showing 0212 and 0329:


The only thing 've done between these two is switching the smartgwtpro jar files.

I haven't had the time to look into this in detail, but apparently now i have to. I want to say that i hadn't expected our skin to break like this just because it's build on top of an earlier version of the same point release.

Just like methods don't disappear or change behaviour, i'd expect the skin to stay the same within a point release, or am i wrong here?

[Isomorphic]

Our apologies for the inconvenience - typically, we wouldn't make public-facing changes to live branches but, in this case, we were fixing bugs for another customer.

On your comments,

a) this was indeed a regression, and an unusual one - our recent fixes corrected/streamlined some logic around how and when DateChooser buttons are created, and it turns out that some of that logic was papering over a previously unnoticed bug, from 2016 - there was a spelling mistake in internal handling of "showTodaybutton" (note the lower-case "b"), which meant your setting of showTodayButton was ignored.

b) setShowFiscalYearChooser() seems to be working as expected, including in our autotests - your code sets it to false, which is the default, so it's not clear what you're expecting to happen

c) these were necessary changes, and were not intended to result in public-facing changes to existing behavior.

On your second point - recent changes allow for a DateChooser to be given a custom size, or be drag-resizable to any size, and still look nice. However, you're correct that there *is* a bug where, if a DateChooser is placed in a layout, it will fill the layout's width, if the layout is wider than the DateChooser.

We'll fix the two bugs and update here when the fixes hit.

[Isomorphic]

You should find these two bugs fixed in tomorrow's builds, dated April 5 or later.