GNOME Bugzilla – Bug 737628
Implement searches
Last modified: 2017-04-17 18:20:40 UTC
GNOME Calendar currently has only a stub interface for searches. It should be implemented, as it is a necessary feature for a complete calendar application.
Created attachment 287405 [details] First design proposal I've currently designed two trials for the search view. This is the first one.
Created attachment 287406 [details] Second design proposal The second design trial.
I think that the date/time is probably the most important part of the search, not the event comment. This means that the date/time should feature more prominently on the left/top of the search results. Google calendar does something like: [Date] [Time] [Entry name] [Extra metadata]
(In reply to comment #3) > I think that the date/time is probably the most important part of the search, > not the event comment. This means that the date/time should feature more > prominently on the left/top of the search results. > > Google calendar does something like: > [Date] [Time] [Entry name] > [Extra metadata] Agree. I like the second one better. Also you should take into consideration [1] Also, I think maybe the rows doesn't need to take the entire windows, and a border around the result list would be better, like [2] [1]: https://github.com/gnome-design-team/gnome-mockups/tree/master/calendar/v.1/search [2]: https://developer.gnome.org/hig/stable/figures/patterns/list-styles.svg
*** Bug 703289 has been marked as a duplicate of this bug. ***
We definitely need an ultimate design approved by the design team. My trials are just this: trials. We shouldn't rely on them to implement the search. I think Reda's designs are very good, and even if we don't implement them as they are, we should base our efforts on them.
Created attachment 289196 [details] Design proposal This is a much improved design. While working on it, I thought so many things: - For the location section, we could use libchamplain. - The three buttons actually mean: [ Information | Participants | Attachments ] - If the user wants to see detailed info about the event, how could that be achieved? - Search could be done not only against the event title, but against: event's source, date and/or time range, other fields (notes, participants, attachments). This is pretty advanced stuff, I think we should support only the minimum functionality first. - Anything else I might forgot?
Let me answer this in order, it will make sense in the end I guess. > - For the location section, we could use libchamplain. Yes, that's the natural choice since that's what Maps use. Now, I don't want to place too much information in the search view. > - Search could be done not only against the event title, but against: event's source, date and/or time range, other fields (notes, participants, attachments). This is pretty advanced stuff, I think we should support only the minimum functionality first. Yes, we should cover most of the string fields, title, notes, email of guests > - If the user wants to see detailed info about the event, how could that be achieved? This is the more important question I guess. I think we should only show some overview of the event here and add a button (like the one in the screenshot) for showing "more details" which will open the edit-dialog. Otherwise we will end-up with two different ways of showing information to the user. Now, this mean that the edit-dialog will have to grow all-mighty, Yes it have to.
Created attachment 289237 [details] Search prototype This is already coded. I have some bits missing but once we agree on the UI there wont be that much left.
I propose some adjustments: - Make each result one-lined (color, date, name, description, [go to day], [more details]) - Highlight the matching text section (maybe with bold + yellow background) - Remove spacing between rows (but don't leave a 2px border between them) - Keep a minimum left & right margin of 96px
Also, search shouldn't be a constant, fixed view by itself, but a dynamic view that is destroyed when the user leaves it. I liked the old titlebar behavior, where it shows a simple title.
I guess the search interface should be exposed as a gnome-shell search provider as well. Maybe there should be a separate ticket about that?
It's an awsome idea, and I didn't even think of that. It should be filled as another bug.
Search is implemented. It can be tracked on 'search-improvements' branch, and soon on master. Further features should be filled as individual bugs. Closing this bug as it reached it's target.