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.
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.
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)
Key scrolling already works. It seems to have some redrawing problems, though. Scrollbars in the month view can be enabled in the KOrganizer configuration.
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.
I agree with the last comment. I also would like to have scrollbars for the whole month. Like there used to be!
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.
*** This bug has been confirmed by popular vote. ***
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. > >
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
I'd like to throw in my vote for the mouse wheel scrolling the month view.
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.
A possibility might be to have Picassa style scroll bars. The more you pull them down the faster the scrolling goes.
Reassigning all KOrganizer bug reports and wishes to the newly created korganizer-devel mailing list.
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.
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.
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
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
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
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 ;-)
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
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.
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!
Thomas, Please commit your patch. Make sure you follow coding style and please add yourself to the copyrights. Thanks!
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
closing