Skip to main content

JXMonthView and zoomable propery

10 replies [Last post]
hobson
Offline
Joined: 2009-02-18

Hello,

I am using a JXMonthView control in my application, to select dates a few years (~1990) back. I am really looking forward full implementation of zoomable property, and I know that now it is in progress/test/not-yet-ready phase. However, I noticed that its API contains set/getZoomable methods, and they are, unfortunately, buggy. When I set zoomable property to true, and scroll a few weeks back or forth, a month caption does not get updated to display new month and year. There is no such problem when just traversable property is set.

I know that it is still in progress, but when API is publicly exposed, I'd expect it to at best not work at all, but not to work buggy. I'd like to set now zoomable property to true and in future just change jar files to new versions, but now it is not possible, and in future, when zoomable functionality is completed, I will be forced to modify and distribute my code too.

Still, I think you all do great work! Cheers!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
hobson
Offline
Joined: 2009-02-18

Yes, I know I might be annoying, and I know that problem is probably related to use-monthview-as-datepicker policy, but I think that I will let you know :) When I click on calendar header elements (month and year link or month traverse arrows) control does not get focus. It occurs when month view has zoomable property set to true (so it displays arrows and 'zoom' link). Clicking anywhere else on the header (that blue area not occupied by any element), as well as anywhere on the header of non-zoomable month view, brings focus to a control just like I would expect it.

Not that it is much of a problem for me now, I think I can live with it, but it seems to be rather counter-intuitive.

Cheers!

kleopatra
Offline
Joined: 2003-06-11

nothing annoying in detecting bugs (at least not for us, most probably for you :-)

Could you file an issue please

Thanks
Jeanette

hobson
Offline
Joined: 2009-02-18
kleopatra
Offline
Joined: 2003-06-11

no code is perfect :-) Sounds like you stumbled across a bug, would you please file an issue in the SwingX issue tracker?

Thanks
Jeanette

hobson
Offline
Joined: 2009-02-18

Issue submitted here: https://swingx.dev.java.net/issues/show_bug.cgi?id=1046
If I only had more spare time, I'd really like to help with this control... Anyway, I think you can count on me with testing and bug submissions ;]

Cheers

kleopatra
Offline
Joined: 2003-06-11

okay, fixed as far as I'll intend to do now (which is not perfect, but in-the-right-direction, IMO). The embarassing part of it is that the code looked like I started to work on the feature and then ... forgot about it, that is there simply was not update if the navigation was triggered elsewhere ;-)

Speaking of navigation (or more precisely scrolling-only, as opposed to scroll-and-select): looks like the JXMonthView needs a richer api. Currently the only scroll methods are

- setFirstDisplayedDay (== show the month which contains the given date as first)
- ensureDayIsVsisible (== do the mininal amount of scrolling to have the given date visible in any of the visible months)

That's goods enough if we have a "linear" only visualization, but fails miserably the moment we add a third dimension (aka "zoomable in z-direction"). Don't really want to expose that. Hoped to hide in the ui-delegate, which might work as long as it's really scroll-only - but knowing developer's greed, expect the requirement to select across those big spans (which would be a load on the selectionModel, isn't very good for keeping lots thousands of dates ... but that's yet another story)

Sorry for whining, but working on the any of the date widgets always gives me the blues ;-)

Will fight it with a good meal right now, cheers
Jeanette

hobson
Offline
Joined: 2009-02-18

Yes, I can realize that writing calendar stuff is not easy task.
Still, I think that introducing a pre-Vista Windows behaviour for selecting year (clicking on year shows edit field and spinner) would be much easier, would not require to introduce new elements (year view, decade view, century view, models, apis, etc.), and would fill this gap, giving devs time to work on fancy 'zoomable' behaviour.

Maybe I will try it some day :)

Cheers!

kleopatra
Offline
Joined: 2003-06-11

maybe - or maybe not: that additional edit field and spinner could just look funny in the context of a datePicker, wouldn't it? The bottom line probably is: lazy me isn't going to implement something intermediate which isn't usable as-is as dropdown for a picker. Contributions welcome, the incubator is waiting :-)

BTW: you are probably aware that you can have the per-block (as f.i. per-year) spinning if you install a DefaultFormatterFactory on the picker's editor? IMO, the incubator has an example. It's a sub-optimal user experience, though ...

Cheers
Jeanette

kschaefe
Offline
Joined: 2006-06-08

> maybe - or maybe not: that additional edit field and
> spinner could just look funny in the context of a
> datePicker, wouldn't it? The bottom line probably is:
> lazy me isn't going to implement something
> intermediate which isn't usable as-is as dropdown for
> a picker. Contributions welcome, the incubator is
> waiting :-)

Just to keep nitpicking, Jeanette, but you're continuing to make the same mistake that I mentioned in the other thread: treating JXMonthView as a JXDatePicker drop-down first and always. We need a separation of concerns, if the month view is ever expected to be a well-functioning, fully-realized component.

Karl

kleopatra
Offline
Joined: 2003-06-11

yeah, I love my mistakes like family

filed an task issue to strengthen the JXMonthView api as a separate comp

https://swingx.dev.java.net/issues/show_bug.cgi?id=1054

Jeanette