Bug 81689

Summary: I would like to have scrollbar in the month view. Also the mouse wheel should work.
Product: korganizer Reporter: vdbergh
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: wishlist    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Mandrake RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: First proposal for a scrollbar in monthview
Improved version of the patch, mouse wheel support added
Further improvments, removed scrollbar and added buttons, optimizations
Next version of the patch
Screenshot of the new Monthview

Description vdbergh 2004-05-16 15:54:10 UTC
Version:            (using KDE KDE 3.2.0)
Installed from:    Mandrake RPMs

I would like to have scrollbar in the month view. Also the mouse wheel should work.
Comment 1 JT Moree 2004-09-13 16:44:07 UTC
And while we're on the subject of month view.  I find it VERY difficult to use.  It seems to be linked to the small month view in that it small month scrollbuttons will change both view BUT big month view does NOT mirror the small month.  Whereas the small month shows the current month, the big month view shows what seems to be the selected day (in the small month) at the top of the big month.  IF they are so linked in that changing one changes the other then they should mirror and show the ENTIRE current month on big view. I would like to see the future weeks as well but PLEASE show me the 1st day of the current month.  That is what is in the small month view and ALSO the type of calendar that everyone is used to looking at on paper.

I have  VERY hard time figuring out from one click to another on the small view where I should be looking on the large view.  The only distinguishing feature is a VERY small Month name on the first day of any given month.  like May 1.  It needs to be highlighted or somthing to make it stand out.  That would be unneccessary if it always showed up at the top of the screen bc then I would know where to look for it.  Right now it is at some changing place on the large view.

There used to be colored highlighting on the current month but it never worked properly for me. Perhaps that is why it is gone.  If it worked it was a good guide to help you find the month you were looking for.

Perhaps an option to always show the entire selected month in the large view would help.  those who enjoy the current view could continue and those who find the current view unhelpful would be helped.  

Scrollbars would work pretty easily in either view and could be linked to the scrollbuttons on the small view.
Comment 2 lparrab 2004-11-03 23:19:36 UTC
Not only a Scrollbar is needed, but also key (arrow) scrolling.

It should be posible to "give focus" to a day by clicking on it in the 
month view ( the day should be highlighted ) afterwards you should be able to scroll with the arrow keys ( and with scrollbar)
Comment 3 Cornelius Schumacher 2004-11-04 00:13:34 UTC
Key scrolling already works. It seems to have some redrawing problems, though.

Scrollbars in the month view can be enabled in the KOrganizer configuration.
Comment 4 Claudius Wettstein 2004-11-04 10:35:36 UTC
Am Donnerstag, 4. November 2004 00:13 schrieb Cornelius Schumacher:
> ------- You are receiving this mail because: -------
> You are a voter for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=81689
>
>
>
>
> ------- Additional Comments From schumacher kde org  2004-11-04
> 00:13 ------- Key scrolling already works. It seems to have some
> redrawing problems, though.
>
> Scrollbars in the month view can be enabled in the KOrganizer
> configuration.

But not for the whole month: I would like to hold the mouse-pointer 
anywhere over the (big) month view, move the scrollwheel of my mouse, 
an see the whole month view scroll line by line. Same with a 
scrollbar on the right of the m.v, spanning over the whole height of 
the view.
As it works e.g in Evolution or in Outlook, and this is IMHO a very 
intuitive feature, which ist missed by several person I know using 
Korganizer.

Comment 5 vdbergh 2004-11-05 19:05:47 UTC
I agree with the last comment. I also would like to have scrollbars for the whole month. Like there used to be!
Comment 6 Jakob Petsovits 2004-12-04 22:46:35 UTC
The question is, if there is a scrollbar, where should it range? You can't pack infinity into the scrollable range, because then the scroll handle would be infinitely small and a small move would scroll by a large amount of weeks.

So I can currently think of two alternatives (there will surely be others too):

- Make the current view range to be the center of the scrollbar range. The scrollbar then always ranges a few months ahead and a few back. Maybe the ones in the past aren't as important, so maybe there should be more future months than past ones. This approach would feature constant scroll handle size, including the feeling that scrolling by a certain amount always goes forward or back by the same amount.
(Short example: If the current month view shows December, you should be able to scroll anywhere between last November and coming March. If you scroll to March, the view updates and the scroll handle - not the view - goes back where it previously was, so now you're able to scroll between February and June. Of course, the amount of months that range back or ahead on the scrollbar is just a quick assumption.)

- The second approach would be to make the scrollbar range between today and the shown month, with some additional months outside. This makes it possible to come back quickly today and everything lying between today and the view. (Yes, I know you can do that by "Go to today" too.) But if you are deep in future months, the scroll range will become very large and therefore scrolling will be less exact and more difficult. (Example of this approach, assuming that today lies in December: If the current month view shows December, you should be able to scroll anywhere between last November and coming March - like in the above example. If you scroll to March, you're now able to scroll between (still) last November and coming June. If you go three years forward, the scrollbar range includes everything from last November until three years ahead (say, 3 years + 3 months, because I had them in everywhere else too). This is certainly too much, I think.)

- I just thought of a third one which takes up my second approach, but limits the scroll range. So, in the example where I go three years ahead of today, the scrollbar would nevertheless range no more than, say, 6 months back of the 3 years ahead date.

Man, I'm getting too complex. I think I should stop right now.
Comment 7 Jakob Petsovits 2004-12-04 22:48:25 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 vdbergh 2004-12-05 13:02:44 UTC
Hi,

I am not sure if you remember but the old korganizer had 4 vertical 
buttons (or
maybe even 6 I don't remember)
on the right of the month view (where normally the scrollbar should be).
They had arrows  <<  <   >  >>  (and perhaps <<< >>>) (rotated 90 
degrees) on them. In this way you could
scroll week by week and month by moth (and perhaps year by year). This 
seemed quite satisfactorily
(albeit ugly) to me.  I don't remember if there was an autorepeat.


It is not clear to me how to duplicate this effect with a traditional 
scroll bar. Perhaps one should
have a scroll bar which scrolls say 1 year, together with a small button 
(a couple
of milimeters across) below it to re-center it on the current position.




Regards,
Michel Van den Bergh
Jakob Petsovits wrote:

>------- You are receiving this mail because: -------
>You reported the bug, or are watching the reporter.
>You are a voter for the bug, or are watching someone who is.
>        
>http://bugs.kde.org/show_bug.cgi?id=81689        
>
>
>
>
>------- Additional Comments From jpetso gmx at  2004-12-04 22:46 -------
>The question is, if there is a scrollbar, where should it range? You can't pack infinity into the scrollable range, because then the scroll handle would be infinitely small and a small move would scroll by a large amount of weeks.
>
>So I can currently think of two alternatives (there will surely be others too):
>
>- Make the current view range to be the center of the scrollbar range. The scrollbar then always ranges a few months ahead and a few back. Maybe the ones in the past aren't as important, so maybe there should be more future months than past ones. This approach would feature constant scroll handle size, including the feeling that scrolling by a certain amount always goes forward or back by the same amount.
>(Short example: If the current month view shows December, you should be able to scroll anywhere between last November and coming March. If you scroll to March, the view updates and the scroll handle - not the view - goes back where it previously was, so now you're able to scroll between February and June. Of course, the amount of months that range back or ahead on the scrollbar is just a quick assumption.)
>
>- The second approach would be to make the scrollbar range between today and the shown month, with some additional months outside. This makes it possible to come back quickly today and everything lying between today and the view. (Yes, I know you can do that by "Go to today" too.) But if you are deep in future months, the scroll range will become very large and therefore scrolling will be less exact and more difficult. (Example of this approach, assuming that today lies in December: If the current month view shows December, you should be able to scroll anywhere between last November and coming March - like in the above example. If you scroll to March, you're now able to scroll between (still) last November and coming June. If you go three years forward, the scrollbar range includes everything from last November until three years ahead (say, 3 years + 3 months, because I had them in everywhere else too). This is certainly too much, I think.)
>
>- I just thought of a third one which takes up my second approach, but limits the scroll range. So, in the example where I go three years ahead of today, the scrollbar would nevertheless range no more than, say, 6 months back of the 3 years ahead date.
>
>Man, I'm getting too complex. I think I should stop right now.
>  
>


Comment 9 Bram Schoenmakers 2005-03-17 15:09:08 UTC
CVS commit by bram: 

Addressing some issues in monthview:

o Make sure the first day of the selected month is on the first row. (#56546).
o Show month name and year above cells.
o Give selected cells a sunken effect.
o Select cell when selected from minicalendar.

o Cleanup in MonthViewCell: Merged cellClicked() and selection() to select().

CCBUG: 52517, 81689
BUG: 56546


  M +74 -40    komonthview.cpp   1.122
  M +5 -2      komonthview.h   1.61
Comment 10 Luke 2005-05-04 22:52:27 UTC
I'd like to throw in my vote for the mouse wheel scrolling the month view.
Comment 11 Eugene Nine 2005-07-15 17:38:20 UTC
I would like to have scrollbars as well similar to other programs such as MS Outlook or Lotus Notes.  Range suggestions could be:
1. user definable, option in Month view under Configure Korganzier to specify range such as +/- # of days/months/years
2. Scan ical file upon opening and set range to fisrt and last dates found in the ical file.

Scrollbar will hit limits when end of range is reached, however arrows on scroll bar will still be functional (as with other programs) and will simply continue to step through the weeks as they would if the scrollbar was not at either end.  This seems to work fine in other programs as most users I have observed seem to instinctivly hit the arrow buttons to try to make it move furthur.
Comment 12 vdbergh 2006-06-01 15:51:19 UTC
A possibility might be to have Picassa style scroll bars. The more you
pull them down the faster the scrolling goes. 
Comment 13 Reinhold Kainhofer 2006-11-02 18:58:00 UTC
Reassigning all KOrganizer bug reports and wishes to the newly created 
korganizer-devel mailing list.
Comment 14 chris-kde 2007-01-24 01:17:55 UTC
I can see that there are issues that need to be considered with a scroll bar in the month view. But is it possible to at least implement mousewheel scrolling without a scroll bar.
I'd find that very useful.
Comment 15 Ronny Standtke 2007-08-11 21:31:27 UTC
I think the scrollbars "invented" here clash with all UI design ideas what a scrollbar actually should be. But you get my vote for mousewheel scrolling. This is something I tried at the very first moment when I saw the month view and miss it badly.
Comment 16 Thomas Thrainer 2008-01-29 00:56:38 UTC
Created attachment 23340 [details]
First proposal for a scrollbar in monthview

Hi!

I also always wanted a scrollbar in monthview, so I tried to make one ;-)
So far no mousewheel-scrolling is supported, but maybe I look into that.

I am not very experienced in writing KDE/Qt code, so some feedback would be
very appreciated.

Also, the solution with the scrollbar at the right is not optimal (because of
the "infinity" issues, so I think I will change that, I actually do not like
it...)

I changed the display of the background colors, so that the same month has
always the same color (every second month has the same color). It was quite
strange to have the months changing color as soon as another months becomes the
"primary" month. This was just to try the look and feel, so I would like to get
some feedback too.

And finally I have one technical question:
I tried to sync the selection in the "small" month view (navigation bar I
think) with the "big" month view. Therefore I emit datesSelected() signals
(defined in koeventview.h), but it does not work. It seems that this signal is
not connected. Where could I connect this signal?

Again, some feedback would be very appreciated,

Thomas
Comment 17 Thomas Thrainer 2008-01-31 00:55:22 UTC
Created attachment 23376 [details]
Improved version of the patch, mouse wheel support added

Hi

I found some time to improve the patch, but it's still not as I would like it
to be. I don't know when I will find the time to continue, so I just post it
right now... release early, release often ;-)

I added mouse wheel support and improved the handling of selections in the
month view (when you scroll, the selected cell also scrolls, when it gets
"invisible" (out of range), and "visible" again, it is still selected, ...)
It is now also possible to select a cell with simple left click (instead of
selecting it via right-click -> context menu).

I also want to add support for creating a multi-day-selection, but maybe in
another patch ;-)


Another question: When there are some events displayed in the month view,
redisplaying takes quite some time (also in other views). Is this due to the
early state of the KDE4 version, or is displaying and updating events in
general a quite lengthy operation?

If I find some time, I want to optimize the scrolling code a bit, but it would
be good to know how expensive re-querying of events/tasks/etc. is.

Regards,
Thomas
Comment 18 Thomas Thrainer 2008-02-04 23:22:26 UTC
Created attachment 23419 [details]
Further improvments, removed scrollbar and added buttons, optimizations

Hi

Another version of the patch.

Current features:

o Go up and down using the mouse wheel

o Go up and down using 4 buttons at the right of the month view (up and down,
month and week). I removed the scrollbar again, I finally did not like it to
jump back to the middle position after dragging it somewhere.

o If just moving by a week the already displayed days get "recycled". This
means that the days are moved to the new position, and only those which really
have to change are updated.
This implies sometimes visual artifacts (the old content is visible at the
wrong position for a very short time).

o If a day is selected, the selection is remembered even when scrolling to
another month and back.

o Months always have the same colour (chosen if they are even/odd). I made the
colour of not-primary month slightly brighter, as this no longer implies that
they are currently not interesting. Maybe it would be good to rename "primary"
to something more obvious.

o Maybe something else I currently not think of ;-)

Thomas
Comment 19 Tomas Pospisek 2008-02-05 02:17:34 UTC
I heard that there's a usability team in kde. I don't know if it's of 
interest to you, but it could be fun to talk to them. They might have some 
ideas how to make the scrollbar's beahaveour really intuitive...
*t

On Mon, 4 Feb 2008, chiefaua wrote:
[...]
> Another version of the patch.
>
> Current features:
>
> o Go up and down using the mouse wheel
>
> o Go up and down using 4 buttons at the right of the month view (up and down,
> month and week). I removed the scrollbar again, I finally did not like it to
> jump back to the middle position after dragging it somewhere.
>
> o If just moving by a week the already displayed days get "recycled". This
> means that the days are moved to the new position, and only those which really
> have to change are updated.
> This implies sometimes visual artifacts (the old content is visible at the
> wrong position for a very short time).
>
> o If a day is selected, the selection is remembered even when scrolling to
> another month and back.
>
> o Months always have the same colour (chosen if they are even/odd). I made the
> colour of not-primary month slightly brighter, as this no longer implies that
> they are currently not interesting. Maybe it would be good to rename "primary"
> to something more obvious.
>
> o Maybe something else I currently not think of ;-)

Comment 20 Thomas Thrainer 2008-02-07 21:02:22 UTC
Created attachment 23466 [details]
Next version of the patch

Hi

This is the next version of the patch. This time it covers other bugs too:

http://bugs.kde.org/show_bug.cgi?id=148753 (Scroll bars in month view cells
useless because of faded content)

http://bugs.kde.org/show_bug.cgi?id=150067 (page down/up should scroll month
view by a month)

in some points http://bugs.kde.org/show_bug.cgi?id=52517 (Month view very
difficult to read)


MonthViewCell's are now styled using Qt style sheets. Therefore I have defined
some properties for the MonthViewCell and use these properties in the style
sheet. The style sheet is reapplied whenever these properties change.
I made this change because formerly all the styling-stuff was spread out all
over the MonthViewCell class. This was quite confusing and led to some
not-so-predictable results. Style sheets group all the styling information and
provide a more flexible styling.
I will attach a screenshot of the new month view.

There were also some minor changes, the most important I currently think of:
I removed mDateToCell from KOMonthView. This map was used to associate QDates
to MonthViewCells. But there is a QVector holding all the MonthViewCell-pointer
anyway, and you can easily compute the index in this array (using
QDate::daysTo()). I tried to benchmark the performance difference, and
computing the index is about 2 to 3 times faster as using the map. And getting
rid of the map saves me from quite a lot book-keeping work while scrolling the
view ;-).

Another issue was displaying of Todo's in the monthview: I had some problems
with all-day Todo's, but that's resolved now. (I don't know if the problem
existed before).

And while waiting for the compilation of the current KDE trunk, I added an
option to turn off the display of icons in the events. There was some bug
report around about that, but I couldn't find it right now...

Possibly there were some other minor changes I currently not think of ;-)


It would be cool if somebody could look at the patch, and maybe even test it
briefly. 

I also plan to add support for selecting more than one cell in the month view
(a date range I guess...) and to improve display of multi-day-events. Should I
just improve my patch for this or create another one (which would be quite
difficult, I think...)?

Regards

Thomas
Comment 21 Thomas Thrainer 2008-02-07 21:04:45 UTC
Created attachment 23467 [details]
Screenshot of the new Monthview

A screenshot showing the new month view in action (note the small buttons at
the right). All the cell-styling is done using stylesheets and could be easily
changed.
Comment 22 Allen Winter 2008-02-07 21:51:10 UTC
Looks very nice.

Maybe you would like to apply for an SVN account and joint the korganizer team?  We really are short on man/woman power.

I will definitely move this higher on my to-do list.

Thanks!
Comment 23 Allen Winter 2008-02-09 17:33:04 UTC
Thomas,

Please commit your patch.
Make sure you follow coding style and please add yourself to the copyrights.

Thanks!
Comment 24 Thomas Thrainer 2008-02-09 19:18:19 UTC
SVN commit 772912 by thrainer:

o Use of Qt style sheets to define appearance of month view cells

o Month have now alternating colors (computed automatically from the colors
  defined in the configuration). This makes it easier to see what's going on
  while scrolling.

o The month view is now scrollable. Four buttons are provided to go back and
  forward one week or one month. The mouse wheel works too. Going back and
  forward one month using PgUp and PgDown works too.

o Added an option in the configuration to turn on/off the display of icons
  in the month view (can save some space, if the icon is not so important).

o Some optimizations, mainly related to scrolling the month view.
  - removed the hash mDateToCell. It is about 3 times faster to compute
    the index in the mCells array using the start date and the date we
    want to get cell from. getCell() does this now.

o ToDo's with only a due date (but no due-time) were not displayed
  (because KDateTime is invalid in such a case, altough KDateTime::date()
   returns a valid date). This is fixed now.

o When clicking on the background of a month view cell, the cell was not
  selected. This is fixed now.

CCBUG:81689
CCBUG:150067

FEATURE:
GUI:



 M  +501 -233  komonthview.cpp  
 M  +110 -41   komonthview.h  
 M  +3 -0      koprefsdialog.cpp  
 M  +5 -0      korganizer.kcfg  


WebSVN link: http://websvn.kde.org/?view=rev&revision=772912
Comment 25 Allen Winter 2008-02-10 15:20:17 UTC
closing