GNOME Bugzilla – Bug 406269
Large number of Favorites or Recently Used apps difficult to navigate
Last modified: 2007-08-29 14:48:18 UTC
I have a problem with gimmie-applet 0.2.3. Even if I reduce the scope to "Today", I have 15 apps in Applications->Recently used. I have 17 in Computer->Favorites. As you can tell, I use a lot of different apps all the time. In both of these windows I have to constantly scroll around to get to programs I use every day. I also have a fairly large number of recently used documents, but that's more manageable for me by changing the date scope. Clicking on Computer or Applications and then scrolling around requires more work than navigating the Gnome hierarchical menus and breaks one of the main ideas behind gimmie, getting to frequently-used stuff as quickly as possible. You could expand the window size or decrease the tile size based on number of items, but I'd hate to see inconsistencies across Topic windows or constantly changing tile size/window size based on changing use patterns. So I don't know exactly what to recommend, but I do know that something needs to be done to handle this use case more gracefully as I'm sure I'm not the only Gnome user with similar needs.
So SVN change #310 adds basic window resizing to fit the number of items displayed in the current icon list. To get this required working around extreme GtkIconView buginess. Try it out and let me know how it works for you. Eventually, we should be able to tune the layout to fit better into the available space: shrinking icons and text based on needed size, not on the current lame count-based layout.
Created attachment 82723 [details] Screenshot of bad window resize With the new window resizing changes my Topic windows are resized incorrectly. That is, the window is resized too small causing the name and description about the Item to be cut off. Attached is a screenshot of what I mean.
I updated to svn 313. This works very nicely for most topic windows. When the tiles are resized to a smaller size I actually find them more attractive than the bigger tiles normally used. In the windows where this works, this completely addresses my problems with usability. There are a few glitches: - while some of the windows reduce the tile size so there are two columns of tiles (excellent!), others still have a single column with scrollbar. For me, Applications->Games and Applications->System Tools do the latter. - again, for me Applications->Internet reduces tile size and has two columns, but then there's a big empty space at the bottom as if the window height calculation is done as if there's a single column. - if you increase the timeframe for "Recent ..." windows to 1 month, the window drops down to the original small size with scrollbar. Decreasing the timeframe after that no longer changes the window size. - separate issue: the histogram that now appears with the + and - buttons is (to me) confusing -- I was originally going to let you know about spurious graphical garbage appearing next to the + and - buttons before I realized what it was! I'll file a separate bug about this. I would love to give you screenshots, but gimmie seems to grab all keystrokes when it has focus so I can't invoke gnome-screenshot without switching away from the gimmie windows, which makes the window disappear! I will file a separate bug about that.
Unfortunately, all the bugs you mention are known, and are bugs in Gtk's IconView... Filing the bugs you see in the gtk+ product would be the best thing. Then you can mark this bug as dependant on those bugs. In the mean time I'll try to find more workarounds. Wrt the histogram: ya, it's still a work in progress. Please file a bug if you have ideas for improving it. Wrt screenshots: this is an X limitation. You can work around it by using gimp's screen capture function set to capture the whole screen after a certain timeout. Then crop out the gimmie window from the result.
(In reply to comment #4) > Unfortunately, all the bugs you mention are known, and are bugs in Gtk's > IconView... Filing the bugs you see in the gtk+ product would be the best > thing. Then you can mark this bug as dependant on those bugs. In the mean time > I'll try to find more workarounds. I'll give that a shot, though it might be a couple of days before I get a chance. Is there any additional info that isn't apparent to a user that I should include in those bugs to make the issues involved clearer? > Wrt the histogram: ya, it's still a work in progress. Please file a bug if you > have ideas for improving it. I did file a bug, bug 409318, but as you'll see from that I don't really know what you're trying to do with this feature. It could just be my lack of understanding, of course. ;-) > Wrt screenshots: this is an X limitation. You can work around it by using > gimp's screen capture function set to capture the whole screen after a certain > timeout. Then crop out the gimmie window from the result. Okay, thanks for letting me know about that feature.
I'm running 0.2.4 now and it seems you have successfully worked around many of the items I mentioned above. I would consider this one closed. Thanks very much, gimmie-applet just gets better every new release!
"I would consider this one closed" Actually, I'm suffering all of them. "if you increase the timeframe for "Recent ..." windows to 1 month, the window drops down to the original small size with scrollbar. Decreasing the timeframe after that no longer changes the window size" happens here: http://img525.imageshack.us/img525/4263/pantallazofa0.png http://img240.imageshack.us/img240/8025/pantallazo1if9.png "again, for me Applications->Internet reduces tile size and has two columns, but then there's a big empty space at the bottom as if the window height calculation is done as if there's a single column" http://img361.imageshack.us/img361/1500/pantallazo2ve4.png By the way, changing the screenshot command from "gnome-screenshot" to "gnome-screenshot --delay=SECONDS" should should fix all your menu shooting needs.
David, please try out the latest SVN. I've just committed some tweaks in change #353 that seem to work pretty well for me.
Thanks Alex, do you know where I should download the SVN from? I skimmed the webpage, but it doesn't seem to be specified anywhere.
To checkout from anonymous svn: svn co svn://svn.gnome.org/svn/gimmie/trunk gimmie To build from that checkout (basically it's the same as building from the tarball, except you replace "./configure" with "./autogen.sh"): cd gimmie ./autogen.sh --prefix=/usr make sudo make install
Sorry to bother again, but after running ./autogen.sh --prefix=/usr I get this error message: Checking for forbidden M4 macros... ***Error***: some autoconf macros required to build gimmie were not found in your aclocal path, or some forbidden macros were found. Perhaps you need to adjust your ACLOCAL_FLAGS? I would really, really appreciate it if you could give me a hand here :(
Well, I'm autotools-stupid, but here are some questions we'll probably need answered: -What version of automake are you using? -What distro are you on? Version? -Do you have gnome-common installed (or whatever package contains gnome-autogen.sh)? I found this bug report stating that automake-1.10 doesn't work right with gnome-common (in Arch Linux): http://bugs.archlinux.org/task/6466 No idea if this is your problem. Personally, I use automake-1.9 on Ubuntu 6.10 with gnome-common installed, and everything works for me.
-What version of automake are you using? automake 1.9.6+nogfdl-3ubuntu1 -What distro are you on? Version? I'm running Ubuntu, Feisty Fawn. -Do you have gnome-common installed (or whatever package contains gnome-autogen.sh)? yep, version 2.12.0-2ubuntu2, it does contain gnome-autogen.sh. Should I downgrade automake to an older version?
Well, I did. automake 1.9 or 1.8 give me the error above, 1.7 or below don't but give me a brand new error message: want_pkg_config='true' shift: 347: can't shift that many
We're up to 0.2.7 and all of these items are fixed. Part of that may be gtk+ fixes as of 2.11.6. Not only are the glitches gone but the resizing happens much more smoothly now. I don't see any reason to keep this open, if any developers disagree feel free to reopen.