GNOME Bugzilla – Bug 381357
Feature Request: Allow PullDown Menu Wrapper When No Notification Tray
Last modified: 2008-02-27 01:30:51 UTC
We are struggling with the fact that users do not understand the notification tray, and there are ways to start up Tomboy with no UI presented on the screen at all. We are proposing that under two conditions: 1) The notification try is not pulled out for the user -or- 2) Via command line flag That the Tomboy search/table of contents UI comes up with a pulldown menu. This will allow the window manager to grab it and give the users *something*. It's very possible we would just make this UI the default to be consistent. Attaching mockup.
Created attachment 77500 [details] Mockup
Is this necessary with the newest releases which open the search dialog when tomboy is run with another instance already running? This does require dbus, which I know is a pain point for you. I don't think the menubar in the search dialog is necessary though. By default it lists all notes in reverse-chrono order, same as the menu. The only feature missing is creating a new note. Maybe we could add another button for this? (Pinning doesn't really make sense in this dialog since all notes are listed)
Alex- I know these types of changes make you cringe :). I was really hoping for a way to have a all-in-one UI that the window manager can grab and not require the notification tray for them. They really aren't getting it at all, and not understanding how to use that. So I wanted to come up with a way to allow them to add additional notes. I thought a full pulldown looked cleaner than just a button that says [New Note] or something, but could live with that if you hate the pulldowns. The pulldowns kind of provided a consistent interface with GIMP, Evolution, Firefox which they use all day. Regarding the pushpins from the pulldown, we have a few people with hundreds of notes and I thought it might be nice to allow them to keep them right in the menu. I told boyd today on IRC that also it might be cool to allow a push pin directly in the search notes grid area as an alternative. Really, I'm just trying to kick around some ideas to get it deployable and get more people use it. dbus for 200 concurrent sessions is a last resort.
I know I've gotten a lot of heat writing applications that don't contain a menu bar (and just run in the notification area) because...they don't work very well for the visually impaired. I don't see a big problem in adding a menu bar to the search menu, especially when the Notification Area isn't present (I need to actually try this myself to see what happens w/o modifying any code).
Created attachment 77521 [details] [review] Stubbed patch for placing a menu in the Search All Notes dialog.
Created attachment 77990 [details] [review] Complete patch for this enhancement. If anyone has concerns about this patch, please let me know. I'll commit it into CVS once it's determined to be "good." FYI: This patch also introduces the use of Gtk.UIManager. This means that we can eventually move the Note Toolbar and Tomboy's Recently Changed Menu (menu that pops up from the TrayIcon) into this as well. It will mean that plugin writers should have an easier time integrating into the UI.
This patch needs some work still. After re-enabling my NotificationArea, the Search All Notes window isn't behaving like I thought it should. I've got to figure out how Gtk.UIManager works a little better before calling this patch golden.
Boyd, can you explain what the point of the menubar is? I really don't get it. If it is that people can't do certain things without the tray icon, then what things, and can they be added without a menubar? As with a New Note button? A new sortable column in the search page holding the pin icon? If it is accessibility concerns, I would prefer to wait until someone actually reports an issue before adding lots of extra UI for 99.9% of users who don't benefit from it.
I guess the biggest question is...what should happen when the Notification Area isn't present? When it's not present, there are a few things users _cannot_ do without any modifications (if they are using DBus): 1) Quit Tomboy - Possible Solution: we could use the Notification Area detection code (inside this patch in Tomboy.cs) and set a flag so Tomboy would quit when the user closes the Search All Notes dialog. 2) Create new notes - Solution: Add some sort of button to the Search All Notes window? 3) Access the preferences - Solution: ? 4) Show the about screen - Solution: ? 5) Show the help documentation - Solution: Add F1 accelerator If there's no Notification Area and DBus is _not_ enabled, the Tomboy process runs completely invisible and users cannot do anything. Possible Solution: Use the Notification Area detection code (inside Tomboy.cs in the patch) and open the Search All Notes dialog for them. Then make tomboy quit when the user closes the Search All Notes dialog. I would agree that there's likely a very small number of users who run without a Notification Area. So yeah, I guess 99% of users shouldn't be bothered by a menubar. The question is, what should be done to solve this problem? These are the options I can think of right now: 1) Ignore the problem and tell people they should use the Notification Area! :) 2) Treat the Search All Notes dialog as the main window and add a menubar as implemented in the patch in comment #6. 3) Same as #2, but only show the menubar when the Notification Area is _not_ present. 4) Only use the Notification Area detection code as described above but do not add a menubar. 5) Use Notification Area detection code and pop open a Tomboy TrayIcon in a separate window and place it near a screen corner. Also automatically pop open the Search All Notes window. 6) ??? Something else related...if users are having a hard time discovering the TrayIcon, we could add a help "bubble" to it when Tomboy runs for the very first time (e.g. http://www.musipal.com/~boyd/ifolder-welcome-bubble2.png).
The issue for us is that people are not using Tomboy because they can't figure it out. Those that have figured it out love it, and tell other people how well it works...they click on it once and it does nothing for them and they never try it again. I would say 90% of our users do NOT have the notification area installed, many had it initially and just removed it because it was taking space away from icons on their panel. They don't know what it was or is, and just took it off. As Tomboy works now, in this case when you click the icon it does nothing for them at all. I am in favor of adding a menu bar, not for me, not for Alex, not for Timothy...but for the 90% of the bell curve that just is not getting how to use Tomboy. These are mostly general office works, police, firemen, secretaries, executives. Everyone understands a pulldown menu, and having it drop back to that UI in the event of notification area being missing will present them with an interface they already know. Firefox has one, Evolution has one, OpenOffice has one. I don't want to change how it works for the power users, but would like a command argument to bring up UI that the window manager will grab and therefore users will see and understand. Tomboy is just one of the best parts of GNOME, and I would like to get more people using it.
Created attachment 78222 [details] [review] Working patch Please try out this patch and provide your feedback.
Created attachment 78224 [details] [review] Example of how a plugin could extend the recent changes menu This really belongs in a separate bug, but this is a sample of how a plugin could now extend Tomboy's recent changes menu using the previous patch (via Gtk.UIManager). Regardless of whether we include a menubar on the "Search All Notes" dialog, we ought to still integrate in the Gtk.UIManager. I can attempt to separate these out into separate patches if needed eventually.
Created attachment 78243 [details] [review] Patch that works without Notification Area and adds "--search" command-line This fixes an exception that occurred when no Notification Area was present. This also makes the "--search" command-line option work when DBus is disabled.
Created attachment 78245 [details] [review] Patch to fix RecentChanges content_vbox correctly Sorry for all this patch spam. I had to rearrange the VBoxes a little. It should be working now.
I've thought about this a little today and I have a proposed solution for Tomboy (mainly with no panel applet, no notification area in mind): * Search window should become re-purposed as a main window * Main window should start up by default (when Tomboy is run as an application, from a launcher -- it seems Boyd already took care of this today) * Main window should have a menu bar * Size of search area should be trimmed down (dropping "case sensitive" toggle, defaulting to case-insensitive search makes sense, at least to me) * Close button on the new main window should be dropped, as the window moves from a dialog to a standard window * Title of the new main window should be changed (currently, as a search dialog, it is "Search All Notes") * Adding some additional features may make sense in the main window, such as adding a contextual menu in the list of notes, enabling one to perform actions on a note, such as deletion, exporting, printing, etc. Perhaps we might want to make a lot of these changes regardless of the status of a panel applet or the existence of notification area?
A more radical approach to making Tomboy more discoverable, more usable for our users is to possibly consider a list / preview way over interaction, much like a mail client, but dealing with notes. If a user double-clicked on a note, it would show up in a new window. When the user follows a link from a note window, another note window appears. A link followed in the "preview" pane area would cause the newly retrieved note could be displayed in the preview area (with some limited browsing capability -- "forward" and "back"). This approach would introduce new users to Tomboy in a familiar looking and acting application (similar to a mail client), yet would allow for Tomboy to keep working in the way users are used to (when calling notes from the applet or notification area, a new note appears by itself in the note view). Another advantage with this special list & preview view is that (possibly in the future) a sourcelist on the left side could be introduced with saved searches, tag "folders" (if tagging is a feature in the future), etc.
Created attachment 78365 [details] Screenshot of new menubar provided by this patch
Created attachment 78385 [details] [review] Patch that's ready for check-in This patch provides the following: - Adds a menubar to the Search All Notes window - Adds UIManager capabilities to Tomboy - Adds global actions using Gtk.Action - Enables "--search" option for non-dbus - Opens the Search All Notes window if the Notification Area isn't present (and it's not being run as a panel applet) I plan to check this in shortly unless there's a really good reason I shouldn't.
Checked-in to CVS. If the menubar showing up on the search all notes window is a problem for power users, we can add a gconf setting to not use it.
Okay, this is awesome. Adding the actions-base framework so plugins can eventually interact with all parts of the Tomboy UI has been on my todo forever. Totally awesome job Boyd! And the menu bar isn't so bad I guess. :) David, does this change solve your problems?
(In reply to comment #20) > Okay, this is awesome. Adding the actions-base framework so plugins can > eventually interact with all parts of the Tomboy UI has been on my todo > forever. I believe there's still some work to do to clean it up the UIManager stuff, but this patch was quickly morphing into multiple issues all boiled into one (1300+ lines).
Alex, Tim: I have been working with Tim on the IRC and testing as he has been making the changes. It's just excellent for us. I have been moving a few power users to the new build and they are testing and really like it. The new SLED 10 server is going to be deployed city-wide around January 10th, and so everyone will pick up this new release. Thank you!
Closing this, as it's already checked-in.
Modifying default assignee and qa contact to be tomboy-maint@gnome.bugs.