GNOME Bugzilla – Bug 460922
log viewer revisited
Last modified: 2011-03-31 17:59:49 UTC
The current log viewer is a little bit too fancy. It can be simplified: (and discussed) - one page dialog, HIG compliant (see blocks) - search as you type or "Find" button-default action - look and feel: ala tomboy -search? or tracker? (http://jamiemcc.livejournal.com/8837.html) or beagle? (http://beagle-project.org/Image:BeagleScreenie_crop.png) or ala gnome-search-tool? (http://www.gnome.org/start/2.12/notes/en/figures/figure-search.png)
Marc-Andre> could you please attache the work we did at guadec, even if it's not ready yet? Like that I can continue the job... Or do it yourself if you still have time for hacking. Thanks.
*** Bug 447856 has been marked as a duplicate of this bug. ***
*** Bug 447855 has been marked as a duplicate of this bug. ***
*** Bug 449048 has been marked as a duplicate of this bug. ***
*** Bug 459147 has been marked as a duplicate of this bug. ***
*** Bug 459148 has been marked as a duplicate of this bug. ***
*** Bug 459152 has been marked as a duplicate of this bug. ***
Yes, Gossip's log viewer is a complete and utter disaster... :)
Bug closed as duplicate contain the following requests: * should use contact alias * should close with Esc or Ctrl-W * typing some letters should search contacts starting with these letters * search bar under text, search as you type, always visible or not? * search "all contact" discussions by default * no tabs, rb smart pl approach, or g-search-tool I am looking into this bug know, based on the (limited) work we did during GUADEC :)
Created attachment 96252 [details] style gnome-search-tool without icon, on the top
Created attachment 96253 [details] gnome-search-tool copy
Created attachment 96254 [details] options expanded
Created attachment 96255 [details] style gnome-search-tool, or bottom search bar
The previous mockup proposals are not fancy, but try to be functionals. Given that a better search UI could be offered by tracker/beagle/... I don't know if too much effort should be put here. (Of course, the emapthy UI could remain and use an indexer, I am not sure what the future will bring) I did not like the "list of discussions" + "discussion content" approach. Too much overhead: I'd rather have the matching discussions directly. Must have IMHO: multiple keyword, multiple contact, and some date search. There is many way to show discussion log.. If you think how gmail handle it, it is completely different, again :) let's discuss it before changing the code!
I discussed the log viewer UI over launch with Jurgen and Tuomas. They could have good opinions about it. Your comments are welcome. Hopefully, the mockups aren't so bad :)
To provide a better desktop integration, maybe Empathy should not provide any UI to search into logs but only expose those logs to "desktop search" facilities. In Xesam [1], the ontology [2] defines a mapping through xesam:IMMessage. From my understanding of the system, the options for Empathy are: - explicitly provide the logs to systems like Beagle/Tracker which are (or plan to be) Xesam servers (and then search into logs directly from their very own UI). That solution allows Empathy to not care about indexing; - directly define a Xesam server [3] in Empathy to expose the logs (that would be accessible through whatever application using the Xesam interface for search UI). Concerning the purpose of that bug report, the log viewer UI would disappear, being replaced by external desktop search tools. What are your thoughts on this? [1] http://xesam.org/main [2] http://xesam.org/main/XesamOntology [3] http://xesam.org/main/XesamSearchAPI
What ever the solution is, the display of messages must be done by empathy using EmpathyChatView. Tracker can be used to index/store conversations bug once the user found the needed conversation it should be displayed using libempathy-gtk's widgets.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 619866 ***