Do-ifying GTK+ 3.0 31 January, 2009
After reading Aruiz and Dylan I think I could ask your attention on that topic.
I like Dylan’s idea of a Do-ified GTK+ 3.0, it seems innovative, making user interaction more accessible and faster. At least, this is my personal opinion.
From Dylan:
@Cimi: it would be great to see Do-like functionality incorporated in Gnome 3, not just on the desktop, but also at the application level. Programs like the Gimp or Inkscape use a lot of keyboard shortcuts that may be hard to memorize all-at-once. Using the Do-metaphor *within* the application will let you invoke functions quickly, and discover keyboard shortcuts in the process.
I don’t have anything against Mono, but for Do to become an integral part of the Gnome Desktop, I think it would almost have to be part of GTK+, because it needs to communicate with other parts of the interface to know which functions are applicable given the situation (it makes no sense to list ‘Crop to selection’ as an option when nothing has been selected).
I must agree with him, sometimes keyboard shortcuts are complicated to use: how can I remember alt+g, alt+k, alt+y, alt+s, ctrl+alt+h, ctrl+alt+h+super+t+f12+enter+backspace? (omg I’m not playing the piano 
I just want to use my computer!!!)
Typing “fullscreen” is easier than remembering Totem is using “F11″, Banshee “F”, another application “Ctrl+Alt+F” and so on… And while “fullscreen” is something known and famous, what about exotic shortcuts that almost each application has? Those are just useless… and dangerous! Imagine if I press “Ctrl+W” on an important document because I forgot the right command…
Now, your thoughts please 
Posted in Compiz, English, GNOME, GTK, Icons, Murrine |
31 January, 2009 alle 17:27
For me, personally, this would be the holy grail!
Most of my web applications are designed to be used in that way for that reason. Even my pre-web apps (from the dawn of time) had do-ish functionality. I like it a lot.
If this was done it would probably be a good thing to do a lot of user testing first; i’ve had quite a few complaints about the “none do”-like functionality beeing hard to use and that the do-like functionality hard to discover.
31 January, 2009 alle 17:36
I won’t say anything about Mono because that’s not my call to judge what can get in or not, but from a user point of view (and I’m one user of GNOME), taking only functionality into account, I would say +1
I agree that Do-like functionalitty integrated at the core of GNOME would be awesome. I’m a Linux/GNOME and MacOSX user and use Quicksilver on MacOSX and Do on GNOME.
I feel like I’m completely lost when I get to a machine where there’s no Quicksilver or Do installed and I need to do everything using the mouse.
31 January, 2009 alle 17:48
keyboard shortcut are the only thing that really speed up someone’s everyday work. I don’t mind how many they are, i memorize them and i use them, everyday. If you’re suggesting to standardize keyboard shortcuts on gnome count me in, but if you are proposing a new way to use or summon them.. a DE without them isn’t worth using.
31 January, 2009 alle 17:54
@marco:
both of them of course, and the idea is something similiar to this (crop a level in the Gimp):
“[metakey] to summon the Do-ified widget, type “crop level”, [enter]” -> “Crop the selected level” runs.
Of course it should work with “cr lvl” or even smaller typings, just like Gnome Do and Enso do.
You don’t have to worry learning all the shortcuts for all the applications, or asking developers to fix the external applications, which are not forced to use the official gnome shortcuts.
Basically gtk+ should 1) provide a widget/window for the typing process just like Enso or Do, 2) grab each application shortcut and store the shortcut’s strings “Crop the Image, Enable Fullscreen…” for the user locale (so we don’t have to worry about the translations) 3) search between those strings when summoning the functionality.
31 January, 2009 alle 17:58
first step: “ninja” shortcuts become optional
second step: “ninja” shortcut option gets removed
effect: those poor fools how are clever enough to remember those “ninja” shortcuts are unhappy with gnome and leave.
more seriously
i don’t think that shortcuts are that hard to memorize as you claim. reasoning: if they would be hard to memorize there wouldn’t be that many coders implementing this feature.
i rather claim if you cannot memorize some action’s shortcut you just don’t use it very often. there fore this shortcut is useless for you. this doesn’t mean that this shortcut is not usefull for a large number of other users: different tasks require different shortcuts to be used frequently.
other problem with do-it like shortcuts: isn’t it stupid if “shortcuts” suddenly become as long as shell commands? what’s the point of using shortcuts then. probably would be faster to access them via main menu when changed to do-it style, which would be just stupid.
seems you are proposing a problem in search of a problem. especially if i consider your exaggeration of the problem: “ctrl+alt+h+super+t+f12+enter+backspace “. come one, this exaggeration is just stupid and really doesn’t support your claim.
31 January, 2009 alle 18:08
I think this would be a very innovative idea I would like to see in 3.x. Definitely +1!
Interestingly, I recently watched a Google TechTalk of David MacKay presenting Dasher - a GNOME accessibility application that is a good on-screen-keyboard replacement. Near the end of his talk, he mentions other possible uses of Dasher. One of which was being able to control your desktop and applications through Dasher (about 44:23) similarly to what is being described above.
Dasher is no Do replacement, but maybe development in this area can help both Dasher and Do.
Link to video:
http://video.google.com/videoplay?docid=5078334075080674416
31 January, 2009 alle 18:09
@5:
No one said to remove shortcuts, also, Do-like functionality will continue to live *over* normal shortcuts: Do-like interface will browse between the application-enabled shortcuts, it’s like a “search engine for shortcuts”.
No, do-like shortcuts won’t become as long as shell commands. If you have used do, you know how it learns your most used items so you could start firefox with “f”. Same thing could happen for shortcuts. And really I never typed the whole command for any of my installed software.
““ctrl+alt+h+super+t+f12+enter+backspace“. come one, this exaggeration is just stupid and really doesn’t support your claim.”: can you see the difference between a joke and the serious part of the post? that is clearly and exaggeration to make people laugh. At least I laughed
31 January, 2009 alle 18:18
Hi,
I don’t use Do, but I am extremely happy with Mozillas Ubiquity, which is probably similar in the way to use it. I love Ubiquitiy very much, and the commands don’t get as long as shell commands, at least not if you use the auto-complete functionality (like tab in a shell, which is the reason why shell commands can be long without the need to type them in full). The “fullscreen” command is a good example: “META fu ENTER”. I don’t use it often enough to learn the shortcut (F11) and I hate to have to use the mouse. So that’s great.
The other feature I love about Ubiquity is the ability to refer to the current selection as “this”. Like in “map this” “translate this” and so on.
But it has to be clear, that I would never want my emacs shortcuts to disappear, because the ones I use very often, have to be as short as possible. The ones I don’t use very often are already very long in emacs: “META+x menu-bar-mode” is something to type (again, if you don’t use auto-completion …).
So in short: I would love to have this on the gtk+ level (not gnome level, not in mono)!
31 January, 2009 alle 18:27
-1
You would say ‘why?’.
Well, I have the opinion that most of the efforts today in the Gnome desktop are for solving hacker’s problems than user’s problems. And this is one. Although typing “fullscreen” may seem more “human” than “CTRL+F” or “F”, it doesn’t remove the fact that it’s still something you access with the *keyboard*. And most users only discover the features of the desktop by “visualization” and “mouse accessibility”.
We have to keep designing with people in mind, not with what only pleases the hackers. Or we will only be “that rare system which that rare guy uses”.
31 January, 2009 alle 18:37
To what level is integration really necessary? I would say that you don’t need to integrate all of Do, but that it should be sufficient to define some interface where an external application/service/library can be plugged in to provide the Do-like interface.
Eg the application only provides a list of operations it supports while the Do-app would care about mapping input to operations.
31 January, 2009 alle 18:40
Maybe this could be an infrastructure for a future interface where keyboard is substituted by touch and speech recognition.
Example, saying:
<Fullscreen>
<Copy>
31 January, 2009 alle 19:17
The idea of having a Ubiquity-like widget in gtk+ that could integrate with ActionEntries and whatnot is pretty cool, though as Andres says, it’s pretty much an advanced user feature.
I like Do as it is…standing outside my applications, tying everything together through dbus interfaces, launchers, etc. I don’t know if I’d like summoning Do and having it behave unpredictably because the available actions change depending on what application has focus.
When you use Do, you develop reflexes and habits after it’s trained. It would really suck if you couldn’t trust those reflexes and habits anymore.
31 January, 2009 alle 19:21
@Andres,
Would recommend you check out the Google TechTalk by Aza Raskin and do some reading around the topic. According to a reasonable amount of research, finding items in a menu is good when the programs aren’t that complex, but given the complexity of today’s programs it’s actually an incredibly painful way of using and finding functionality.
A text interface alone might be a bad idea, but if the language is fairly natural (e.g. “paste this here”) and plenty of hints are provided to the user (e.g. suggestions as you type) then I think you’d be surprised at how much easier it would be for all users. Not to mention that the vast majority of users only use and only need to use a small subset of the total functionality available in an application, it would be pretty easy to pick up
+1 for this idea!
31 January, 2009 alle 19:29
[...] sul blog di Cimi la sua proposta molto [...]
31 January, 2009 alle 19:42
Fantastic idea!
+1
31 January, 2009 alle 19:59
The idea of being able to control more parts of the app via the keyboard again is great
Maybe someone could step ahead implementing such thing as a demo in banshee (as it is Mono and Do is and people tend to be extremely innovative with both).
Would really love to see how that would work out.
If it does, it should be done at GTK+ level of course
31 January, 2009 alle 20:04
I can appreciate the effort that goes into choosing sane keyboard shortcuts, but implementing a (subset) of Do within GTK+ would not undo those efforts.
Besides, even if shortcuts are chosen with utmost care, once the application is translated into a different language, it doesn’t make that much sense anymore. And there are other reasons why some shortcuts may be non-intuitive. Take for instance Control-V for ‘Paste’. I can only guess that Control-P was already taken for ‘Print’, and the letter ‘V’ happened to be right next to the ‘C’ used for ‘Copy’ on qwerty keyboards.
Application-level-Do will not replace keyboard shortcuts, and if anything, it only serves as an easy way to discover new ones.
Some other thoughts:
- It is better suited for full-screen interaction with applications: menubars and toolbars can be turned off at the user’s discretion to free up screen real-estate. Great for Gimp or Inkscape.
- Implementing Do at the application level means only the menubar, toolbar and help system need to be parsed, so it would be very lightweight.
31 January, 2009 alle 20:06
I think this idea has huge potential, just think about chaining commands or writing “macros”.
E.g.
“Open Picture1, flip horizontally, shrink to 800×600, save as Pic2.png”
Of course you would use auto-complete and type only first couple of letters of each command.
That could be very powerful and simple to use, you just “speak” to your computer and tell it what to do…
As Pippo noted, in the future you probably won’t even need to type it, you will just say it.
It looks like a goal worth pursuing.
31 January, 2009 alle 20:15
Oh, here’s another one. I was kind of holding back on it because I was afraid Matthias might come down on me like a lead balloon, but here goes:
GTK+ Do-functionality (+ dbus) = lazy man’s dream come true to quickly ‘Clutter-fy’ existing Gnome/GTK apps.
31 January, 2009 alle 20:53
wow, I just tried ubiquity and for the few commands that exist in a browser it is really awesome
Much like Do is. So in favor of DE-wide Do functionality
31 January, 2009 alle 21:03
I love this idea. It also seems like a natural place for the linux desktop to get ahead… the text interface of tools like bash and emacs is truly excellent, and I think we can demand the same of the text interface for our apps (think of how far firefox has come, for example). I love the idea of a toolkit-central way to access menu items, etc. via the keyboard (via “search”, essentially). Especially with complex apps like openoffice, it would be enormously helpful to be able to type commands (imagine: super-key + “left margin 1 inch” or some such — even if “super-key + para” got me to the paragraph settings dialog, that would be pretty good.
31 January, 2009 alle 21:24
Definitely keep an eye on what the Ubiquity folks are doing; they are not just writing code but also thinking a lot about the implications.
Agreed completely that enabling this desktop-wide would be very interesting. But there is no reason it has to wait for a mythical ‘GNOME 3.0′- someone could easily start prototyping such a widget now, and getting it into just a couple places (gedit? nautilus?) would be a huge demonstration of the power of the idea. Do it!
31 January, 2009 alle 21:40
Nice idea. Also see this recent comment on another blog:
“Hey Guys,
We are happy to help you guys get Ubiquity-style thinking into Gnome. Come get involved with the project — and we can figure out how to let Ubiquity escape the browser.”
Posted by: Aza Raskin | 01/30/2009 at 05:19 AM
http://aruiz.typepad.com/siliconisland/2009/01/aza-raskin-on-m.html#comment-6a00d8341fa10a53ef01053702fb38970c
31 January, 2009 alle 22:33
that would be awesome, well conceived keyboard driven interfaces are very intuitive, flexible and powerful, add to that the bling and hipness Do seems to have and a bit of good doc and both tech savvy and new users will be able to proficiently use it
i also agree that getting rid of the mono dependence is a need, not that i hate mono but because it makes no sense to make gtk depend on it, and putting this directly on gtk would be the best, then not only gnome apps but any gtk app could take advantage of that functionality
good work, keep it up
31 January, 2009 alle 22:46
It sounds like you are reinventing Emacs.
That’s a good thing.
31 January, 2009 alle 22:51
Another option would be to have GTK export the list of keybindings/actions somewhere. That would allow external apps, like Do, to hook in and do funky things.
Actually, this would allow more than just Do behaviour; this could be a way for whole-desktop scripting to work. If it’s at all feasible - I’ve got no real feel for that :).
31 January, 2009 alle 23:19
so uhm, applescript?
31 January, 2009 alle 23:27
I think that when starting, apps should export a list of functions and the fields they require over DBus so any thing like Do, Launchy and Enso can allow access to them
Then there ought to be three options for using them
1: through an extra field in DO (I.e first select app, then select command, then select fields 1-n)
2. Through a separate invoke key (ie Super-Space for system wide, ctrl-space invokes on main app
3. Make them available on a ’sub dock’ that extends from that application’s place on the Do Dock.
The DBus solution avoids links to Gnome and being stuck with app incompatibility for non-gtk apps. Also allows different quicksilver-a-likes to tap in to the functionality…
31 January, 2009 alle 23:44
Cimi: “ctrl+alt+h+super+t+f12+enter+backspace” would probably just kill your X server, not a great shortcut
That stuff would really rock, count me as +1
About the shortcut thing, the Do-widget could just have more functions, as Gnome-Do does: when you type “fullscreen” it could send you to fullscreen, show the shortcut, locate for you the menu entry, let you change the shortcut and so on…
Just one thing, coders out there: do it before M$ steal the idea, put it in windoze7, patent it and claim it as its!
1 February, 2009 alle 0:19
“Nobody will remove shortcuts” - hopefully. Current trend in GNOME looks different: Someone wants to profilate and invents half-backed feature. Someday someone realizes the half-backed feature is redundant with some old but working feature, and removes the old feature.
1 February, 2009 alle 0:20
RAOF: This idea actually makes quite some sense.
1 February, 2009 alle 0:22
Ulisse: Nah, no risk for patent. There is prior art in Emacs, vim and each half serious CAD application.
1 February, 2009 alle 0:55
[...] zu sehen, dass der Erfolg von GNOME DO zu interessanten Diskussionen [...]
1 February, 2009 alle 1:56
while i do like the idea of Do, i think if it were to include mono in any way, the gnome desktop will be digging itself a hole that MS will throw the dirt on top of whenever they want…anyone who thinks otherwise is dreaming. They are a business who’s sole purpose has been to smash the competition, and they will do that to linux desktop through novell if mono gets into gnome more and more. Sorry to make my post about mono more than the great concept that Do is, and I really do think gnome needs something to keep up to speed with KDE in 3.0, but hopefully mono isn’t part of that picture.
1 February, 2009 alle 2:09
@34:
read the post again, no one is thinking of merging Do inside Gtk+.
We are discussing about implementing some ideas of Do inside Gtk+, and that will be coded in C
1 February, 2009 alle 3:23
Wait, so you’re saying that instead of typing just a key or two (F11 or C), we instead type out what we want to do (fullscreen or copy) with some other keystroke designating that? Also, those strings will have to be translated, whereas things like F11 won’t. I’m all for improvement and such, but why not get everyone to use the same keyboard shortcuts? They would be _much_ more likely to use that than a totally new system.
1 February, 2009 alle 4:24
@Cimi:
Here’s another idea along the same lines: a keyboard-shortcut-learning-mode that can be toggled on/off in the ‘Help’ menu. Whenever the mouse is used to make a menu- or toolbar selection for which a keyboard shortcut exists, the shortcut will briefly be super-imposed over the work area and then fade away. Sort-of like training wheels. If you see the shortcut often enough, you can’t help but remember it eventually.
I’ve been pondering this one for a while too: A method to export the menubar contents over dbus. There are some cases where it would make sense for either the panel or the window manager to render the menubar (for instance, to combine the window title and menubar into one area, like Vista, or to put the application menu in the panel like Mac OS X).
Here’s how I imagine this to work:
When a GTK+ application is launched, it looks for a registered handler. If one exists, it foregoes rendering the menubar, and instead forwards the contents of the menubar over dbus to the application that is registered to handle these events, for example Compiz. Compiz then renders both the window title and menubar.
1 February, 2009 alle 4:44
@Matt:
Yes, the first few times you may have to type a few letters more to find a command. I’m all for keyboard shortcuts, and this will *not* replace them. But tell me, have you memorized every single shortcut in the Gimp? Blender? Inkscape? I didn’t think so.
This could help you find them. Just type ‘crop’ and it would not only activate ‘Crop to Selection’, but also show you the keyboard shortcut.
PS
I realize that Blender is not a GTK+/Gnome application and thus will not benefit from Do-goodness even if it is integrated into GTK+. But one can dream
1 February, 2009 alle 5:08
@Dylan:
I see where this could come in handy. Now that I’ve thought about this more, (which I should’ve done before 
) I could really like this idea. (Though I still think everyone should use the same shortcuts.)
Ah, I hadn’t really thought of that.
1 February, 2009 alle 5:31
Short message; I just wanted you to know I agree the idea looks promising even if it needs prototyping and testing.
1 February, 2009 alle 5:35
I think its a great idea
+1
1 February, 2009 alle 7:56
Wouldn’t it be better to implement this outside of Gtk+ with the already existing a11y infrastructure?
1 February, 2009 alle 9:35
mmm
so gnome 3 will be a giant graphical text adventure?
“gimp open file.png”
“crop”
“cut”
…
“kill”
“inventory”
1 February, 2009 alle 11:43
+1
I know it would be a lot of work, so maybe we will see that implemented in two years, but that’s a great idea.
I never use any shortcuts, except for CTRL+C and CTRL+V, so I would say I’m for it.
Oh, and that would bring Enzo (search for Humanized google talk) idea to the next level.
1 February, 2009 alle 16:57
OT, however: The CTRL-W thing kills me when I use nano which uses it for saving, then any sane program where it shuts the window.
Having a version of nano with standard shortcuts would save me closing a lot of windows!
1 February, 2009 alle 16:58
ZeD: This would actually be great for with speech recognition… whatever happened to sphinx 2 anyway ?
1 February, 2009 alle 18:11
@Stu: CTRL+W in nano is for searching, not saving
But I agree, we need a better nano. Do you want to help me in an effort to develop a nano-style editor with sane shortcuts? I’m starting to code it with mono.
Regards.
1 February, 2009 alle 18:18
@Andrés G. Aragoneses oops, good catch… I’m doing bits of code here and there on shoebot for the moment (and am quite slow on that)… so can’t for the mo, but might submit some patches when it’s going - host it somewhere and I’ll follow it + see how it goes.
I reckon whats needed is something that runs in text mode, but has standard shortcuts where possible…. (maybe this exists already).
- Most existing textmode editors are a little bit odd when you use them as well as desktop apps… they are useful tho for quickly editing stuff + especially when X can’t come up.
2 February, 2009 alle 10:35
Eclipse has this (Ctrl+3) and it’s really really useful for all the things you seldomly use. It works for actions, views, preferences and pretty much everything. For example, type “bookmarks” and you get the bookmark view. Type “jre” and you are on the “Installed JREs” preferences page. No need to hunt through the menu and search for the item, the name is enough.
So, definitely +1 on this!
2 February, 2009 alle 12:28
+1
Very bright idea.
@Andrés G. Aragoneses
Ther could a visual UI element that, when clicked, pops up the DO UI with a nice message.
2 February, 2009 alle 22:58
This is a great idea. I’ve been thinking about something very similiar for some time, actually. There are a few issues that I can think of that it is worth considering (this is all a bit of pie in the sky, I’m afraid):
_Integration with existing interfaces_
Integration is important both in order to make discovering/learning the new input system as easy as possible, and in terms of making the user experience satisfying. GUIs could indicate which text input would reproduce instructions issued using point and click, as well as react to the commands fed to them by the new text command system. In terms of integrating with existing text interfaces, it is worth remembering that we already have a number of text based interfaces on the desktop (search boxes are one example, address bars in web and file browsers are others). Could these be made to use the same engine as the one that you’re talking about, or to plug into it in some way? Imagine if Epiphany’s address bar could use the new system, or Banshee’s search box?!
_Blurring text and graphical interfaces_
Designing this new interface, we should think about how we could start to blur the distinction between text and graphical interfaces. GNOME-DO, Hotwire, Dasher, and mobile devices are already pointing the way forward here. But there is more that can be done. Could the new input system be *both* graphical (with clickable words, etc) as well as textual?
_GNOME 3.0_
The design for the new GNOME shell [1] already has an ‘overlay mode’, and this mode has a facility for text input in the form of a search box. If you were to implement the idea that you’ve proposed here, you would need to reconcile your system with this one, in my opinion. It is important to have as few ‘overlays’ as possible. In my mind, there’s a real opportunity here, then - to integrate this new text input system into the new GNOME shell overlay.
[1] http://live.gnome.org/Boston2008/GUIHackfest/WindowManagementAndMore
3 February, 2009 alle 19:28
Off Topic: There ist this GTK 3 Hackfest and they even want to invite you.
Check that out
http://aruiz.typepad.com/siliconisland/2009/02/gtk-30-theming.html#comment-6a00d8341fa10a53ef011168438610970c
3 February, 2009 alle 19:52
Man, that would be cool… go forward Cimi and bling !!
3 February, 2009 alle 23:15
+10!!!
This is dead of Do/Ubiquity/Quicksilver-ifying GTK is the most brilliant think I have heard coming out of the GTK/GNOME camp in ages (the KDE camp for that matter).
While people may claim that GUIs are more discoverable, I think there is great potential for a search bar for actions (like in OSX in some cases, like in System Preferences), or even just word completion when the command is being typed (like Do/Ubiquity/Quicksilver/Smartbar).
A feature like this would get me a lot closer to switching back from OSX to GNOME.
5 February, 2009 alle 7:16
+1
as long as you leave the shortcuts in apps for people that do know them, i have no issue with improving usability, and as far as fullscreen goes, mplayer has the best keyboard shortcuts for fastforward, rewind, and fullscreen, pause, even tho it’s lacking in other areas.
6 February, 2009 alle 16:04
The idea of exporting menu items over dbus for Do to access sounds good. Do could just have two shortcut keys: one, e.g. Super-Enter, to summon Do as-we-know-it now, which would handle app launching and the like or controlling unfocussed apps (e.g. the banshee plugin), and another (Super-space, maybe) which only handled the actions exported by the currently focussed app. I bascially have this set up at the moment with Do and Ubiquity: Super-Enter summons Do (global stuff) and Super-Space summons Ubiquity (firefox-only stuff).
Use-case/workflow example:
· Jack is listening to music while editing some photos
· Jack presses Super-Space to summon App-Do and types “res 50%” to shrink his photo by half with auto-completion of resize
· Jack presses Super-Space to summon App-Do (or it might even stay open until dismissed with Esc or somesuch) and types “save Photo1-small.jpg” (the save-as dialog pops up so that he can choose a folder if necessary)
· A track comes on which Jack doesn’t like. He presses Super-Enter to summon Global-Do and types “bans skip” to skip it (with “banshee” autocompleted)
· Continuing with his photo editing, Jack uses App-Do to “open Photo2.jpg”… etc
With this approach, only the dbus-export needs to be done by the apps/gtk and Do can handle the rest.
6 February, 2009 alle 16:17
p.s Best of all, interaction mode would then be optional. Once the menu options are accessible over dbus, people who want Do-like functionality can install it & get it. People who prefer mouse-based or conventional-shortcut-based interaction can still use that. Everyone wins!
8 February, 2009 alle 19:56
This would be amazing. This would also help the user discover new features.
13 February, 2009 alle 2:03
I absolutely love this idea.
It is important to keep in mind that while it would currently only be used for text/graphical interface integration, the most important effect is the framework we would build. The ultimate goal is not to type, but to allow for complete voice command over a computer. This is something that people have been predicting for a long time, and while voice recognition is not nearly up-to-par with what it needs to be, it will get there. By implementing this now, we are poising GNOME to explode ahead of the pack when voice recognition catches up and users start asking for voice-controlled computers. Really, I don’t think we can afford not to implement this.
14 February, 2009 alle 2:15
_GNOME 3.0_
The design for the new GNOME shell [1] already has an ‘overlay mode’, and this mode has a facility for text input in the form of a search box. If you were to implement the idea that you’ve proposed here, you would need to reconcile your system with this one, in my opinion. It is important to have as few ‘overlays’ as possible. In my mind, there’s a real opportunity here, then - to integrate this new text input system into the new GNOME shell overlay.
[1] http://live.gnome.org/Boston2008/GUIHackfest/WindowManagementAndMore
I like that idea.
Such as super key + space would drop down the shell and be like gnome do, only with much more space you could have more options.I just hope the search thing is NOT inside a gtk entry.
I want it like gnome do.Just type and it will always work.
18 February, 2009 alle 23:10
I like the concept of gnome-do-searchable keyboard shortcuts, so I’ve paraphrased it and added it to the ubuntu brainstorm here:
http://brainstorm.ubuntu.com/idea/17763
I’d love to see what you could make out of that great core idea.
19 February, 2009 alle 21:19
[...] Andrea “quanto amo la mia spada laser” Cimitan si esprime favorevolmente su questo punto, dicendo a chiare lettere che qualunque utente vuole usare il suo PC, e non suonare [...]
23 February, 2009 alle 18:42
+0.5
-2
It could seem a good idea, but I can think af, at least, 2 big problems.
The first: when I am using inkscape or Gimp, I don’t want to move my right hand from the mouse. Exactly as moving my hand from the keyboard to the mouse to select the style in OOo, it slows down my work and distracts me.
This function could be useful when you have both hands on your keyboard (editing text and data and… uhm… what else?)
The second: i18n.
“fullscreen” is “schermo pieno” (or “schermo intero”) in italian. “Crop” is “Taglia” (or “Ritaglia”. And it clashes with “Cut”…), “Resize” is “Ridimensiona”. Will you take into consideration application locale or will you force the user to learn a new scripting language?
I think Do (and similar) interface is good for application names and file names, as you know you want to load “totem” or “gimp” or “sunday on the beach.jpg”, but it can quickly become a new programming language with tens of thousands of keywords when applied to generic applications. Rexx anyone?
Bye.
16 March, 2009 alle 14:06
+1 it’s a great idea, it would emphasize the concept of Commands in the GUI, it was used before (AutoCAD, and 3d modeling applications were using command lines), but with added autocomplete and one shortcut summoning would be great.
17 March, 2009 alle 1:09
Isn’t there already an interface in place that would allow this functionality to be started? This is taken from an old “What’s new in GNOME 2″ list:
“The core of accessibility support is a set of hooks in GTK that allow an external program to query applications about their GUI. For example, an external program can ask what buttons and menu items there are, their state, what their labels contain, and so on. This can be used by a screen reader to tell a blind user what’s on the screen, for example.
An example of why this is interesting even if you don’t have a disability: you could write a high-level scripting feature with commands such as “activate the File menu, choose Open, select all, copy” - no one’s working on this yet so it won’t be in GNOME 2, but a macro recorder and playback system would be a simple project using the GNOME 2 platform. This kind of scripting would use high-level user-comprehensible GUI features and wouldn’t depend on special application support for scripting, it’d just work automatically with any GTK app.”
3 April, 2009 alle 21:34
[...] Anyway Gnome works very well for me already (version 2.26) so I guess the limited amount of visible changes is a plus for me after all. But one thing I would like to see integrate and officially backed by the Gnome Team is Gnome-Do. My desktop experience took a great leap forward after getting used to this way of interacting with my computer. I while back I read a very exiting blog post about incorporating Gnome-Do to the very core of Gnome. [...]
18 May, 2009 alle 17:05
i sure like your/his ideea. i hope that it will materialized and not just talk.
24 May, 2009 alle 17:23
I am very much for this idea. I have read every comment here and have not seen a convincing argument for why not to implement it. I use dmenu on my system and love it!
*Of course keyboard shortcuts are not going to go away.
*It is not a thing that only hackers will use; people with this argument have obviously not used a gnome-do like program
*I don’t get the i18n problem. It has it built right in since most apps use i18n in their menus.
*It’s much quicker than searching through menus; if I’m using Gimp and I want to use “curves”, I go Image… where’s adjustments? curves?… oh, colors - it should be there (for some reason I’m blind and don’t see it: there are way too many options) then look back under image and it’s not there, look under every other menu item… When all I would have to do is type “curves”. I really see people do this in MS Office: they know it’s supposed to do X, but they can’t figure out how to get there.
This scheme also allows developers to expose more than one command that does the same thing since it won’t be cluttering up a window. For instance, you could have “graph” and “chart” both do the same thing in an office program.
I’d like to suggest that a prototype be made that can take over the alt+space combo. This is normally used to display the WM menu. You could offer all the WM commands plus a text box for entering a command; as soon as someone starts typing, the menu shows suggestions instead of the WM options.
20 June, 2009 alle 8:17
Wow, how did I miss this?
YES.
Even if Gnome 3.0 does nothing else, this feature implemented system wide would be my personal pick for Linux’s killer app.
When programs have translations into other languages, the Do interface would pick up the translated menu items and use them as commands, right?
7 July, 2009 alle 18:56
I already do something similar to this with current gtk menus.
In metacity.. press the combination: Alt+space
A menu will display for you with comands, then you press C for close, X for Maximize/minimize, etc
In nautilus Press this key chain of commands (chained, like in emacs):
Alt+g(go) t(trash)
Alt+e(edit) a(select all)
You don’t have to remember the commands because before pressing any of these keys you are already seeing the keys you have to press, the menu is displayed and showing you the options you have, you don’t really have to remember, but if you remember them you will do it faster.
Isn’t this the same you are wanting?
I think that instead of reinventing and confusing a lot of users, it should be better to improve the current menus to make them be more dynamic, more accessible, try to fix the cases where there are menu items with the same shortcut (why not use another separate key instead of the underlined letter?).
18 October, 2009 alle 8:11
@Ferk
> try to fix the cases where there are menu items with the same shortcut (why not use another separate key instead of the underlined letter?).
Because it is damn hard. Alt+ shortcuts work really well with simple programs like nautilus, but very poorly in super-complicated ones (e.g., already mentioned gimp, audacity, openoffice, inkscape).
Read http://en.wikipedia.org/wiki/Mode_%28computer_interface%29 and think about the reasons people like vi so much (and no, I don’t force to like it as well, if you don’t, that isn’t the point)
27 January, 2010 alle 20:47
Do-ified Gnome Shell - my ideal desktop. I think there is no questinon wether it should be implemended. Rather developers should look upon best practises of Quicksilver, Enso, Deskbar Applet, Google Desktop Linux and such to bring desktop/computer/files under fingertips.
27 January, 2010 alle 22:39
@Matěj Cepl
> Because it is damn hard.
What’s hard? do you mean It’s damn hard to achieve? or do you mean hard to use?
Having a separate key would be easier to use than the current scheme, although still not perfect. Perhaps the best thing would be for the menu to automatically detect when the keys pressed are matching univocally a menu item name
I’m not sure what you mean about vi and modality… both approaches (mine and yours) are modal. Both require the user to enter to some special mode to press letters that trigger different events depending on the mode. The only difference is that yours requires extra keypresses and mine is structured in the already existent tree-like structure.
I guess it just depends if you prefer it with a fixed structure but fast and efficient or you prefer it slow but discoverable.
Although the discoverability would still depend on the words the action chosen and the kind of action (there might be different kinds of “copy”, and there might be synonyms for the action) so maybe there’s still some fixed structure implicit in the words. Also, sometimes you just need to browse the actions to know what are the actions you can do, before you actually need to do anything, and nothing beats the menus for this job.