GNOME Bugzilla – Bug 465658
The in-panel field is gone in new releases
Last modified: 2009-02-18 09:23:07 UTC
Hello! Thanks for making deskbar, a wonderful and useful app. However I was really dissappointed that the newest version does not have the in-panel textfield anymore. I think that was a lot nicer, more usable and less intrusive to my workflow. If I could get a settings in the preferences to get the old behaviour back you could make me _really_ happy. Thanks!
The new window interface has lots of usability issues. Esspecially if you want to use the deskbar to launch an application or a program within say 2 seconds. I am someone who uses deskbar regularly. I use my mouse to reselect history items a lot. I use my keyboard to launch programs, search for documents, etc. a lot. I used to use the text-area inside the pane. With the recent changes, not only has the proccess of using deskbar become so clumbersome and slow, it is also filled with completely incomprehensible interface choices. Why a window? Why a menu in the window? Why history in a pane? It's not a desktop app with millions of functions, that needs its own window and its menu to organize all those functions. It was a little tool to quickly run or search stuff. Here are the usability problems: 1) the time to use it is now 10-12 seconds. First we click, then we type, then we click. Because it is registering as a full blown window (with task-list entry). Severity: CRITICAL 2) links in list entry like this suggest double-clicking. Severity: CRITICAL 3) it takes 4 clicks to select an history item. Severity: CRITICAL 4) when history pane is visible it gets focus instead of the result area. Severity: HIGH 5) when showing the history pane the result-widget moves to the right and the vertical scrollbar is hidden. Severity: HIGH 6) because of the way the deskbar registers itself (as a window) the compiz effects are longer by default. this futher increases the time to launch anything using deskbar. Severity: HIGH 7) when I choose not to launch any action, escape does not close the window. Severity: HIGH 8) it doesn't hide by default when we select an action. this is the expected behaviour Severity: HIGH 9) the result pane is horizontally resizeable. Severity: NORMAL 10) the result pane does not resize with the window. Severity: NORMAL 11) it has menu, yet it has no purpose. a simple toolbar with all three entries would be sufficient. Severity: NORMAL Should I file a bug about all these issues, or will you please just revert back to the old behavior. To why this has happened I can only guess. If not, I do want to thank you guys for the nice work you have done so far. I have used deskbar, almost daily, for a year now. I will miss it, when we finally upgrade to Gutsy Gibbon ;-)
Deskbar applet is, in general, brilliant. However this new window annoys the hell out of me. I generally use it with just the icon in my panel, and the little dropdown box bit opened with Ctrl-Space. This worked great, I pressed Ctrl-Space, typed, and went. Now I press Ctrl-Space, I type and I have to resize the panel so I can see what the hell my options are. And then, if I want to get rid of the window without running anything, Ctrl-Space doesn't do it like it used to! I have to close it properly. For now, I'm downgrading. Please, bring back the old behavior. I don't mind if you want to keep this window functionality as another option, but the old options were more productive for me, and for other people also it would seem since this bug has been reported with 24 hours of the Gutsy update that brought it in, both here and at https://bugs.launchpad.net/ubuntu/+source/deskbar-applet/+bug/131446 . Deskbar applet is very useful to me, but not like this.
I am also very disappointed by the new interface although most of the issues discussed above already cover my thoughts. Although I usually use the drop down text box when the icon is clicked, having a window appear instead is much, much slower and a lot less usable.
I just signed up to add my concern to the changes to deskbar. To me this is a huge step backwards. Please at the least could you give us an option to go back to the old interface.
Add a vote for the old interface. The new window is a usability nightmare. I wholeheartedly agree with many of the comments already made. The old style was very quick in terms of speed and the number of clicks needed. The window style fails on both of those aspects. I like deskbar, but if this change stays I may have to look around for an alternative.
This work was part of a GSoC project - http://code.google.com/soc/2007/gnome/appinfo.html?csaid=CD3CECAA07C74D08
Well, the the project seems to be about a complete refactoring of the code. I can not understand how make it more MVC, would make it problematic to keep the old-style usability. What I really think is going on, is that the project cleaned up the code nicely, but its still alpha as it is not yet usable. They should have kept this version in the trunk until it was actually usable from day-to-day. Usable does not just mean: it does not crash. Usable means, that is still performs some useful function. At the moment it serves no purpose, because launching a terminal and typing a command, or pressing alt+f2 and typing a command, or using the menu to launch a program is all faster and more usable than using deskbar is. Deskbar is not just a good idea. Its a tool me and a lot of people here seem to be using daily. It does not seem this is also true for those developing deskbar. Please, put this version back in the trunk until it is ready. At the moment, it is nothing more than a developers preview. It works, its just not usable.
I'm in too for the *deskbar*. If I understand well, we have in hands a new version still under development. I then hope the deskbar will be back, maybe with whatever new GTK or Gnome API and some eye-candy.
i agree, its a huge step backwards. deskbar is a utility, it needs to do its job, and it needs to do it fast end efficient, without interrupting the workflow.
GNOME is now in UI freeze as of today, so this is unlikely to be "fixed".
I really appreciate the work done on SoC for this, but to make a radical change two days before a UI freeze doesn't seem like a smart decision. There is almost no way to fix any problems with the UI that any users had. If the change was made maybe two weeks before the freeze, it would allow the developer(s) to consider the possibility of reverting. Right now, the situation is "I made a change, live with it." I understand the SoC student wanted to refactor Deskbar, but that doesn't mean we needed a major UI overhaul. I really would encourage the SoC student to request a freeze break if something can't be done about it before 23:59 UTC tonight. http://live.gnome.org/ReleasePlanning/RequestingFreezeBreaks Deskbar was a quick and useful applet, now it has grown into its own application and somehow lost that quick and easy "usefulness" about it.
Reverting back to an old version shouldn't be too dangerous. I won't be suprised if all major distro's choose to backport or remove deskbar from the default setup anyway. So, you can't really loose reverting back to the old version.
+1
+1 big time
One more vote for the old style, does anybody feel this is an improvement? I also would like to echo the statement that a major UI change without any previous discussion, 2 days before UI freeze, is a bad idea. This code should not have made it in before the UI freeze, push it back to the next release so it can be refined and get some user input.
Here are some of the "Features" listed on the deskbar website http://raphael.slinckx.net/deskbar/ "The goal of DeskbarApplet is to provide an omnipresent versatile search interface. By typing search terms into the deskbar entry in your panel you are presented with the search results as you type." -- New UI doesn't provide this, so the primary goal is now broken "Sits in the panel waiting for input" -- Nope "Ability to choose a fixed width or to expand in the panel to fill all available room" -- No Why include a major UI change that removes advertised features and causes it to fall short of its stated goal?
The GNOME bugzilla is not a forum, please don't treat it like one. See http://www.k-d-w.org/node/25
I also support a return to the original deskbar. This is not a bar. It is a button that launches a window. It is not useful this way.
I used to love this applet now it's just useless...
This really needs to be fixed ASAP. Is there anything I can do to assist? Be it development time or donation.
It'll likely be reimplemented during the 2.21 series.
I advice to fix this major bug immediately, this is nothing what can be solved within six months. A major feature is broken and the deskbar-applet is completely unusable. I think developers should communicate more with users and take a look at the own project goals, both failed here :(
Bruce, you say it'll be re-implemented in the 2.21 series. I'm glad you acknowledge it as a feature that is desired by users and will return :) How far away is the 2.21 series and is there anything the opensource community can do to advance its release?
(In reply to comment #20) > This really needs to be fixed ASAP. Is there anything I can do to assist? Be it > development time or donation. > Of course, you can help. The task isn't easy, but if you are willing to work on this issue please join #deskbar on irc.gimp.org and I'll assist you.
*** Bug 501134 has been marked as a duplicate of this bug. ***
Was there any progress in this bug lately?
(In reply to comment #26) > Was there any progress in this bug lately? > No. Work hasn't started and I don't know when I have time to tackle it. Maybe at the end of the year when things slow a little bit down.
What work will need to be done. I have looked at the deskbar applet sourcecode in the hopes that I could figure it out myself, but having never touched Python or GTK before in my life, I was unsuccessful. However, if there is just some tedious refactoring that needs to be done, I can certainly help with that.
wow - I am not alone in my hatred of the new deskbar!!! I gave it a month to try and get used to it. Nope - it is a major step back in usability. I used to use the command-line panel applet every few minutes in my workflow. Then deskbar came, it was a bit slower, but sort of did the same job. Now the deskbar pops out a window - totally against all common sense. Remember the history of this applet - it is there to fill the shoes of the original gnome command line panel applet. It is surprising that such a usability setback would be introduced into Gnome which is the usability leader on linux desktops (IMHO). At least we have the 6 month release cycle and can fix this in the next cycle quickly????
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
I can't reopen the bug but I would have. The focus is not gave to the input field, we still have to grab the mouse and click so the benefit is lost. Could you just add this focus switch for the next beta? (I tested version 2.21.90 which I guess is Gnome beta 1.)
Next software release means Gnome 2.22 or 2.24? Comment #30 is one day later than Gnome feature freeze... http://live.gnome.org/Schedule
Tested Gnome-2.22, looks like Deskbar-Applet can't provide the feature mentioned: * Sits in the panel waiting for input Sits in the panel, doesn't wait for input. Instead it opens a popup or, aeh, a popup!? The average computer-user love the panel an integrated launchers, but the average computer-user DOESN'T like popups. * Ability to choose a fixed width or to expand in the panel to fill all available room Nice feature in connection with the above one, but i'cant use it - see above Why the deskbar-website gives promises, which the application didn't hold for over one year? Sorry. We are just a little bit frustradet, because this is a major-case bug and nothing was done, this is poor :-(
(In reply to comment #30) > The fix will go into > the next software release. Sebastian, since this is still broken in 2.22, are you referring to 2.24? It would be reassuring to know that this has actually been fixed, even if I will have to wait half a year for the fix. Waiting half a year and *not* getting any fix would feel bad :-(. Note that the original report talks about "the in-panel textfield", which is still missing in 2.22. Thanks //Johan
seems that the svn-build can't compile because off oasis-office-something :(
installed svn-version with success - no panel field :-(
My mistake. I was referring to the sticky UI. The entry in the panel *won't* come back. It's tremendously difficult to get focus and navigation right and it only worked previously because of huge, ugly hacks and I don't want to introduce this issues again. In addition, please post only comments that are _directly_ related to this issue.
*** Bug 572161 has been marked as a duplicate of this bug. ***