I just noticed that evolution uses only the default calendar in "Select date" to "search for items" (highlight days). Also, I tend to "only" add "Search previous" and "Search next" buttons to the "Select date" window. Though I'm not sure how with time ranges, as calling "all events before/after selected day" might return quite long list of items. What about some time range forth and back, say 5-10 years, and iterate month by month until the range boundaries? The bad thing here is that the only advantage is the longer time range, otherwise almost nothing. And, of course, quite often asking a backend for a data.

Created attachment 136734 [details] [review]
proposed evo patch

for evolution;

Try this, if you wish. It might mostly work, I believe, though with slower calendars would be not as that great. (My tests work fine here.) Just have some searching on in the calendar view and call "Go To" dialog. It will show search buttons there, with which you can search forward and backward. You can also stop the search or close the window before the searching is done. When searching, it uses all enabled calendars from the UI, not only the default calendar. It also applies the search criteria and highlights only days which contains at least one event there. This applies after the first search, until any user change in the calendar itself, like change of a shown year/month, or the count of months in a window. After that are days highlighted back with a default calendar. Might seem strange, but I decided to use it this way as the searching thread is created only on demand, and searches forward and backward only.

(If possible, I would prefer to iterate on this, rather than resending one relatively large patch again and again.)

The patch contains also some fixes in widgets/misc/ for issues I noticed during testing.

OK I tried the patch and it worked.  A couple of initial observations:

1.  It should not be necessary to click on the day in the calendar to bring up the calendar for that day.  What I mean is that pressing previous or next should bring the calendar to that day.  It need to click on the numerical date is not necessary

2.  The gui should not pop down after clicking on the date.  It should be

3.  The gui should replicate the Search: window so that the search can be refined/changed without starting over

4.  I'm not sure that putting it with the "Select Date" function makes sense in retrospect.  Selecting a date should popdown the window.  Perhaps it should have its own entry

Actually the best solution would to simply add Find-Next/Previous buttons to the left of the Search: window in the main UI.  Clicking them would simply move the calendar to the next hit.  

From a conversation with Milan it seems that this last one isn't so simple at present, so as an alternative 2 new menu entries will be added under  Search (below Find Now).

One other observation:  The search seems to be really slowed down if remote calendars are active.  Perhaps there can be some sort of switch to exclude/include them from the search (probably in preferences).

(In reply to comment #3)
> Actually the best solution would to simply add Find-Next/Previous buttons to
> the left of the Search: window in the main UI.  Clicking them would simply
> move the calendar to the next hit.  
> 
> From a conversation with Milan it seems that this last one isn't so simple at
> present, so as an alternative 2 new menu entries will be added under  Search
> (below Find Now).

I agree here, that's the initial idea, three menu options/button on the bar:
Find Previous, Find Next, Stop Searching.
Very similar to those in the above patch. Unfortunately, in the light of recent discussions about earlier branching and merging kill-bonobo and eds-dbus into master, I believe that this has lower priority, thus any review would be done very late, meaning to rewrite those bits once again, to meet actual sources of that time. Thus I'm postponing this until the above situation will be sorted out.
You can use the attached patch meanwhile.

> One other observation:  The search seems to be really slowed down if remote
> calendars are active.  Perhaps there can be some sort of switch to
> exclude/include them from the search (probably in preferences).

Good idea, I was also thinking about a preference over the calendar itself, something like "Include this calendar in the searching", but I'm afraid that this can be too hidden for a user. I'm not sure whether the global option will make the same effect or better, because I also think that the slowness you saw might be also because of the "Birthday & Anniversaries" calendar, which makes queries on your address books, but the calendar is local.

Definitely not searching all active calendars might seem to users as a bug, because choosing some time interval and seeing there event which "couldn't" be found with find prev/next might be quite surprising. Though that all is just about the default values and probably some proper UI design for the searching.

Hi Milan,

I just had to find the date and time of some meeting I had within the last 2-3 years.    I searched for the keyword, but then had to manually go through all the calendars for the last 3 years.    Any chance this feature can be finished up and comitted?

I hope I'll find time for 3.6, it's rather late for 3.4. (I've this still in my ToDo, I only  didn't find mood and time to dive into it.)

Created commit 49787d0 in evo master (3.5.1+)

OK, it's finally done. I tried to add the buttons beside the "Search:" entry on the tool bar, but it didn't look nice, thus I made them items in Search menu. This also searches in currently enabled calendars, thus if you want to search only few of them, then disable the other calendars. It searches from currently selected day in the given direction, in a range of 10 years by default. This value can be changed:
   $ dconf write /org/gnome/evolution/calendar/search-range-years 15
It's also searching on day basis, thus if you have two events on the same day then searching for the previous can skip the previous event on the same day.

Please write any issues you may find with it here, though it seemed to work fine for me.

General comment: In case that you know the user documentation, a bug report is welcome to update it if it is affected. In this specific case, I filed bug 673929.

I added those buttons beside search entry in commit 62dceeb (3.5.1+)

Excellent.   It works and the user interface is natural.

Couple of things though (maybe unrelated):

1.  Mousing over the new arrow buttons triggers a pop-up help, but it stays up for a very short time, barely enough to read what's said.

2.  If I search backwards for John Doe (in the summary), but as Doe, I get the entries, but the regular appointments show John not John Doe in the calendar.  The full information is there.

Thanks  Milan!

(In reply to comment #10)
> 1.  Mousing over the new arrow buttons triggers a pop-up help, but it stays up
> for a very short time, barely enough to read what's said.

I'm afraid I cannot do much with it, that's the default tooltip timeout, like on any other buttons on the toolbar.

> 2.  If I search backwards for John Doe (in the summary), but as Doe, I get the
> entries, but the regular appointments show John not John Doe in the calendar. 
> The full information is there.

Can it be because of no enough space to draw the whole summary? Just a guess.

Hi Milan,

You're correct about the time for the popup--the same problem occurs elsewhere.


As to there not being enough space, I don't think that's it.  When I switch to day view, there's tons of space, but only the 1st word of the description appears.  If I open the appointment and close it immediately the rest of the summary appears.

hmm, then can be something with drawing, who knows. If you wish we can try to investigate within a new bug report, with some screenshots or so, thus I'll have better idea what is going on here. By the way, did you save the appointment or just cancelled the dialog, like if you took another window and moved above the day view, thus it got repainted? There is a little difference between these two.

*** Bug 612602 has been marked as a duplicate of this bug. ***