After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 483297 - Look of find bar
Look of find bar
Status: RESOLVED FIXED
Product: tomboy
Classification: Applications
Component: General
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Tomboy Maintainers
Tomboy Maintainers
ben[open_task]
Depends on:
Blocks:
 
 
Reported: 2007-10-04 10:22 UTC by Michael Monreal
Modified: 2009-10-04 00:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Screenshot (6.54 KB, image/png)
2007-10-04 10:25 UTC, Michael Monreal
  Details
Patch (2.03 KB, patch)
2008-02-29 12:11 UTC, Michael Monreal
none Details | Review
Fixes the icons (using Gtk.Arrows now) and inconsistencies (1.21 KB, patch)
2009-02-16 20:38 UTC, Benjamin Podszun
accepted-commit_now Details | Review
Screenshot of current (0.14.1) FindBar and patched version in my branch (6.19 KB, image/png)
2009-04-29 16:38 UTC, Benjamin Podszun
  Details

Description Michael Monreal 2007-10-04 10:22:06 UTC
The find bar on the bottom is an element that is found in various GNOME applications. Epiphany, Evince, Yelp all have this feature and they even share a common look. Unfortunately Tomboy has a slightly different look & feel... But it would be nice if it actually looked the same
Comment 1 Michael Monreal 2007-10-04 10:25:11 UTC
Created attachment 96621 [details]
Screenshot

Here is a shot of evince for reference.
Comment 2 Boyd Timothy 2008-02-26 19:16:56 UTC
Setting the default assignee and QA Contact to "tomboy-maint@gnome.bugs".
Comment 3 Michael Monreal 2008-02-29 12:11:57 UTC
Created attachment 106248 [details] [review]
Patch

Going through old bugs I found this still unfixed gem, so I quickly did a patch myself. This replaces the gtk stock navigation icons with gtk arrows. I also removed the icons from the context menu and changed the "previous" string to match the rest of GNOME.

Sadly it's too late for 2.22, but can we put this in early after branching?
Comment 4 Sandy Armstrong 2008-02-29 14:41:35 UTC
Michael, this will make our find bar wider.  We are in fact trying to find ways to make it less wide, even if it means going against the standard (ie, just having "Next" and "Previous" instead of "Find Next", etc).

However, using gtk arrows instead of the stock navigation icons might be able to help us save space.  We'll look at it after branching, as you say.  :-)
Comment 5 Benjamin Podszun 2009-02-16 20:38:27 UTC
Created attachment 128858 [details] [review]
Fixes the icons (using Gtk.Arrows  now) and inconsistencies

This patch changes the next/previous icons to Gtk.Arrows, saving space. Additionally the naming is more consistent (was: "Previous" and "Find Next". Changed according to this bug comments to "Previous" and "Next"). Last change sets the find entry into fill mode, so that it occupies as much space as possible.
Comment 6 Sandy Armstrong 2009-02-16 21:07:15 UTC
I'm not comfortable making this change so close to freeze; would like to do it (or something like it) early next cycle to have more time for user feedback.  Thanks for the patch, Benjamin.
Comment 7 Benjamin Podszun 2009-02-17 01:39:48 UTC
No problem, I fully agree. I set the target to 0.15 for now and add it to my list of stuff to poke the submitters about.. ;)
Comment 8 Benjamin Podszun 2009-04-29 16:38:12 UTC
Created attachment 133578 [details]
Screenshot of current (0.14.1) FindBar and patched version in my branch

Since the freeze is over: This is the current FindBar layout on my machine. The screenshot shows the old layout (above) vs. the new one (below).
Any comments?
Comment 9 Sandy Armstrong 2009-04-29 17:17:55 UTC
I suggest asking on the mailing list, since it affects translated strings and I'd rather not change it back and forth too many times.  Having the find field grow makes next/prev button placement less predictable if you think left->right, or you could argue that it's now *more* predictable for always being in the lower-right corner.

I think I'm fine with losing the "Find" text.

Ask on the list, wait a few days, and assuming nobody objects, I'd say it's fine to commit (for 0.15.0, perhaps).  Thanks!
Comment 10 Olivier Bilodeau 2009-04-29 23:41:20 UTC
Looks good to me. The potential issues I had seeing the screenshot were all explained in this bug.

+1

(I didn't know if I should reply on the list or here. I decided to do it here since I'm just giving a thumbs up)
Comment 11 Sandy Armstrong 2009-05-02 20:22:01 UTC
Push whenever you're ready, Ben.
Comment 12 Benjamin Podszun 2009-05-04 16:05:26 UTC
Fixed in trunk/master
Comment 13 Michael Monreal 2009-05-06 10:41:03 UTC
I can't build master right now. Wondering if there is more space between "Find:" and the entry field than in the screenshot? If not, can he have a little bit more space between those please?
Comment 14 Benjamin Podszun 2009-05-06 11:33:35 UTC
No need to build master, this is part of 0.15.0. I agree that it looks strange though. Feel free to reopen/add suggestions/mockups/patches.
Comment 15 Michael Monreal 2009-05-06 11:59:25 UTC
Got it building. IMHO it would look much more polished with just a little more space (maybe half of what evince has there for example).