GNOME Bugzilla – Bug 328440
beagle-search should know size of window in "More Document Results" and use it.
Last modified: 2009-05-17 17:26:34 UTC
Please describe the problem: When you click on "More Document Results.." and go into the detail screen, it only dislays a fixed number of documents and forces you to click back and forward through that fixed number of documents even though you can have a lot of free white space to display more. It should either: 1) Display all documents at one time and give you a scroll bar. 2) Or display as many as will fit within the current window size and let you page forward and back with that number of documents. If you resize the window, more documents should appear on the screen. The current design forces a lot of clicking around when users have pages of similar documents (which they often do). Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
It looks like based on the new code in the Preferences area that this will not happen? The user will decide how many to display on the pages and it won't happen automatically? Maybe a setting of "0" could be used for dynamic display of as many as will fit on one screen?
The code in the preferences pane is actually very old code that worked with Best and has never been hooked up to beagle-search. See bug 328312
Created attachment 63400 [details] [review] first cut I started working on this (because Nat filled a bug about it on bnc too), but it's a total pain because since the GroupView is in a ScrolledWindow, it has no way of being able to find out if the window shrinks (including in the case where its part of the window shrinks because the details pane has popped up), so it will grow to fit more tiles, but not shrink to fit fewer. (I may come back to this patch again at some point, just attaching it here in case someone else wants to work on it.)
Created attachment 76980 [details] [review] Patch to show more results This is the third version of this patch as revised on the dashboard-hackers mailing list.
Ryan, what is the status on this patch? Are there still any known issues? I will try to review and get this in as soon as possible but I'm a little short on time at the moment.
(In reply to comment #5) > Ryan, what is the status on this patch? Are there still any known issues? I > will try to review and get this in as soon as possible but I'm a little short > on time at the moment. > Joe was having an issue with this patch previously but it should be fixed in this version (the converstaions category would sometimes lose rows when it should have gained them). On the mailing list, Joe's last comment was: > Maybe we should take a different approach? Beagle‑search today handles > resizing of the window as it gets wider, and adds columns. Does a > similar approach not work when making the window longer? (Unfortunately > I don't have a concrete answer, because I'm not totally familiar with > the layout code. Dan or Lukas might be able to guide you better here.) I hope that helps! Please let me know if you run into any issues of your own.
Dan/Lukas/Joe - any news on this one ?
*** Bug 414211 has been marked as a duplicate of this bug. ***
Half-yearly ping :)
FYI, there are patches attached to this bug. Someone who understands the GUI code needs to review and commit them as needed.
These patches still need work.
Created attachment 109251 [details] [review] Fix with GroupView doing the size management
The attached patch adds size management to the GroupView instead of having the individual categories trying to manage their own size. When the pane containing the GroupView is re-sized the GroupView is notified and it distributes the available size to its children (Categories). The Categories use their assigned size to figure out how many hits they can display, with a minimum of two rows if possible.
I've played around with the patch a bit, and I've only noticed one layout problem. But it's one that probably needs to be fixed before it gets checked in. It's somewhat difficult to describe. I will try to figure out a way to do a screencast or something which shows the behavior. But in the meantime, I will try to describe it: My search results come back in 3 categories. Category 1 has 3 matches; Category 2 has ~100 matches; Category 3 has ~100 matches. The way the code is written now, it wants to display at least 2 rows of items for each category. If you don't have enough screen space for this, you will get scrolling. That is fine. My initial window size is too small to hold two rows of every category. I get 2 rows for Category 1 (2 items in row 1, 1 item in row 2). I get 2 rows for Category 2 (2x2). I get 2 rows for Category 3 (2x2). Most of Category 3 is scrolled off the bottom. I can see the title of the category, and part of the first row. My lame ASCII drawing: ___ Category 1 \ XXXXXXXX XXXXXXXX | XXXXXXXX | | Category 2 | Visible on screen XXXXXXXX XXXXXXXX | XXXXXXXX XXXXXXXX | | Category 3 ___/ XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX As I resize the window vertically, I would expect firstly for all of Category 3 to become visible and the unscrolled portion of the area to decrease and eventually for the scrollbar to disappear. As I continue to scroll, I would expect additional rows to appear in categories 2 and 3. For example: ___ Category 1 \ XXXXXXXX XXXXXXXX | XXXXXXXX | | Category 2 | XXXXXXXX XXXXXXXX | Visible on screen XXXXXXXX XXXXXXXX | | Category 3 | XXXXXXXX XXXXXXXX | XXXXXXXX XXXXXXXX ___/ and then growing into: ___ Category 1 \ XXXXXXXX XXXXXXXX | XXXXXXXX | | Category 2 | XXXXXXXX XXXXXXXX | XXXXXXXX XXXXXXXX | Visible on screen XXXXXXXX XXXXXXXX | | Category 3 | XXXXXXXX XXXXXXXX | XXXXXXXX XXXXXXXX | XXXXXXXX XXXXXXXX ___/ (notice the new rows in Categories 2 and 3) Etc., until I can't resize any more, or all the items are displayed. That's not exactly what happens. As I resize vertically, additional rows in Category 2 appear, but Category 3 never becomes more visible. I am seeing this: ___ Category 1 \ XXXXXXXX XXXXXXXX | XXXXXXXX | | Category 2 | XXXXXXXX XXXXXXXX | Visible on screen XXXXXXXX XXXXXXXX | XXXXXXXX XXXXXXXX | XXXXXXXX XXXXXXXX | | Category 3 ___/ XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Notice the additional rows in Category 2, but most of Category 3 still isn't visible. The scrollbar never grows and never disappears. Hope this helps.
Whoops, noticed a little typo in the paragraph between my first two drawings: (In reply to comment #14) > As I resize the window vertically, I would expect firstly for all of Category 3 > to become visible and the unscrolled portion of the area to decrease and > eventually for the scrollbar to disappear. As I continue to scroll, I would > expect additional rows to appear in categories 2 and 3. For example: That last sentence should probably read instead, "After the scrollbar disappears, as I continue to *resize* the window, I would expect additional rows to appear in categories 2 and 3."
*** Bug 376914 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 582354 *** *** This bug has been marked as a duplicate of 582354 ***