GNOME 2.9.4 Development Release

3. F2 selects the file name of currently selected file for changing - but only in nautilus panes not on the desktop. This seems inconsistent.

I just tried - it seems to work for me. I have a faint memory of it not working some time ago, so I guess it was either fixed or there is a bug preventing this from working sometimes.

6. computer:/// has "filesystem" which maps to "/" basically ... it would be nice be able to restrict users views of this - (why should users "see" /usr/ or /etc ??)

That is the whole point of filesystem. If you don't want to see that, you should just go to your personal folder. In non-spatial Nautilus this is also the default place. (And of course it's also right on your desktop.)

1. There should a short cut key for jumping to the "Window Selector 2.8.1" applet.

Filed as bug 141418, though it languished in different locations for a while and only got reassigned to Metacity a few weeks ago. However, it's actually something that requires changing both gnome-panel and metacity and coming up with some communication mechanism (which isn't too bad since similar mechanisms already exist with alt+f1 and alt+f2, as you mention). I saw the bug, didn't need the functionality myself, and didn't think it looked that high priority--much in part due to the comments of those who filed and commented on it. *shrug*

While Alt-Tab cycles through applications on the current desktop where the window selector shows *all* open applications

Currently, yes, but that won't be true under all circumstances in the future. See bug 143511. Your point is still valid, though, in that most people won't have the window list set to show windows on all workspaces.

2.1. With a top panel and menu set up as a "Menu-Bar", Alt-F1 jumps to Applications (if focus is on the desktop). But subsequent letter presses do not jump to the corresponding menu item on the drop down menu which appears. The user must arrow-key-down to the menu item. A problem of X and widget set communication but hopefully something that could be fixed in Metacity.

I don't understand this. What are you pressing and expecting to happen? Oh, and it almost certainly has nothing to do with Metacity--once the user presses Alt-F1, metacity sends a message to the panel to open that menu, then the menu is opened which comes with a grab of the keyboard by gdk. At that point, gdk (running as part of the gnome-panel process) is responsible for all keystrokes.

2.2. In a open window Alt-spacebar pops up the window-bar operations menu. But it is not possible to arrow-scroll onto the application menu from here (this is an X windomanager and toolkit interaction issue of long date).

Yeah, and not an easy one to solve. However, I'm pretty sure it's solvable. I had never thought about this issue until now, and never remember seeing a bug about it (and there are very few people who have read more bugs in bugzilla than me). Is it really important? Is it what the user expects. It could be, I just don't know. However, if it is important to you, then you should at least take the time to file this bug in bugzilla.

2.3. Worse case of 2.1 above: When focus is *on the desktop* typing Alt-Space opens a meaningless window operations menu.

Not anymore; fixed in Metacity 2.9.3

I don't know much about the internals of nautilus/gnome-vfs2, etc. so I'll not comment on your other points.

Worse case of 2.1 above: When focus is *on the desktop* typing Alt-Space opens a meaningless window operations menu. At the least this should be a no-op ... or perhaps it should select the window-selector widget (see 2. above) if it is running

This is strange ... nautilus must create a desktop that is seen as an X "window" - no other WManagers will do this ... you're right that metacity should scan for the WindowName associated with the Desktop and turn off the operations menu ....

Agree that there should be a shortcut for Window Selector

Anyone got a bug# for this??

Yeah, it's bug 148915, which was fixed about a month ago.

network:// shows all your mapped network shares, those that you created via connect to server, these are not connected until accessed. It also shows webdav shares that are found via zeroconf

what about female bonobo monkeys who happen to be carrying 12-packs of beer?

Gensync: http://breakmygentoo.net/archives/cat_help.html ... it's in the portage tree. And it takes very little to set it up only once.

Has the Gnome 2.9.4 ebuilds in a seperate portage tree availible for the masses. Just don't post on the gentoo forum about problems from using such software. They tend to get a touch pissy.

I've had no real problems with either garnome or jhbuild. Using jhbuild to build latest cvs seems to be the easiest for me. 9 times out of 10 if there's a build error, simply removing the directory and starting over will fix it for me. The other time it's usually hunting down another dependency that has been added.

Unfortuneatly not. That is my experience at least. I have never succeeded in using jhbuild or garnome. The latest edition of the Gnoppix LiveCD includes some 2.9 build...

Hi,

Garnome (cipherfunk.org/garnome/), or jhbuild (sorry, can't be bothered getting link *grin*, use google).

Bye,
Victor

As an ordinary user, I'm glad the dialog was added. I always hated having to browse around nested popup menus with ambiguous names trying to find where the applet was that I was trying to add.

... panel-applets:// ...

Well the idea is ok as such, but to utilize this optimally, you'd have to add a new entry to Nautilus->Places. It would seem to be overkill to me.

I, for one, think that the new applet chooser is really good. It gives new users a better glimpse of the abundance of applets available, together with a hint of what they do. I think that the flat list with the large icons and short descriptions, inspires people to go on a little "applet exploration".

How does organizing the applets in a heirarchy rather than a flat list diminish the advanced users' Gnome experience? Seriously, it's not like anyone is proposing taking panel applets away or anything, just organizing them in a way that might make more sense than the current heap-o-applets method.

By the way, 2002 called, they want their stock anti-Gnome rant back.

Ok, I understand what you are saying, but there are like 20 applets in that list, and it is sorted alphabetically. Hmmm...I want a clock applet. Let's see, it is probably named "Clock" or something. *scrolls to C* There it is with a nice description. Drag it onto the panel. Doesn't seem so hard to me. Why do you need a hierarchy for something like that...it sounds like an over-engineered solution to me.

I was hearing people complain about the new add-to-panel program when Gnome 2.8 was first released, but when I actually used it, I thought everything was fine. It is considerably nicer looking than the other, and I think it is also easier to use. Remember, if you are going to impose a hierarchy, it has to be intuitive and obvious if your users are going to get it. Is "Clock" a utility, accessory, eye candy...? Would you put it in a PIM category? If so, you would probably also need some additional PIM applets because one applet in a category is kind of silly. And if you have to go searching through several categories to find what you are looking for, then there is no point to the hierarchy.

Ok, I also understand what you are saying - but you propably are native english speaker, so you have your point of view while other people have different opinion.

Why?

1. Not always list is translated in 100% (in my ubuntu is translated in about 70%)

2. And little example in polish:

Clock = Zegar - this is ok

but...

Weather Report = Raport Pogodowy

in our language we have different syntax.

So, when you will translate Weather Report to "Pogodowy Raport" it could be easier to find applet on list but it is grammatical error.

And in fact these icons should be smaller, they are just too big.

You are right, alphabetical order is great if you are using english. In other languages it could be a real headache to find what you want.

-SF-

>And in fact these icons should be smaller, they are just too big.

I absolutely agree with you here. The list is too big to scan at one glance. One _must_ pay special attention to the list and read all the netries there to be able to add the applet he/she wants.

I can surely say, the older design was much, much better for me.

Please, listen the UI for applet is not something that you see or use very frequently. You either do it once after you compile from sources or you pull out from any distro. Thats it.

I still prefer to use the old menu style, not the sorted one which is very convenient to look from top to bottom.

Your argument against the flat list of applets is basically that it won't scale well for larger numbers of applets. This is true but it is also worth asking both how often something occur and how big of an issue is it when it does.

Pretending that I'm a Gnome developer for the moment, my thinking would be as follows. For most distros, there wouldn't ever be more than 30 or so applets in the first place. In addition to the low number of applets (i.e., whatever came bundled with the distro), the frequency of when applets are added and removed from the panels is very low. Most people spend a few minutes setting up their panels when they first log in and then never change their panel applets again. So, the conclusion is that having a more scalable hierarchy for 'managing' applets is not worth the added complexity to the user interface for the extremely rare class of users that have (a) hundreds of applets and (b) a complusive panel modification disorder ;-).

At least, that would be my rational. I'm not saying that the actual Gnome developers had different and better reasons of course.

PS This is, of course, just my opinion, but you really need to stop playing around with applets and start getting some work done :-P

"But they did waste time on it and they made it worse, not better!"

No they didn't waste it. Now I don't have to browse through absolutely meaningless categories to find an applet. Not that I'd play around with them every day like some people obviously (have to?) do, but still I prefer the flat list over the way it was before.

True, it's not perfect. There *might* be a better way (hopefully). Until someone comes up with it I'm quite fine with the way it's now. If we'd always wait for the perfect solution, nothing would get done.

30 applets are already way too many for a flat unsorted list. Maybe 10 would be pushing it but 30 is way too much. Especially when you consider that for most applets alphabetization is not meaningful. Clock is a good example where that might work but what about things like window list? This could be task list, application list, etc.

Adding a couple layers of meaninful hierarchy is not "overengineering". Seriously that is just unfair. I'm not talking about adding more hierarchy than what we have in our main menu and no one is proposing we get rid of that! Obviously there are more applications to be organized but the same engineering logic applies easily to either case.

And, I agree that putting clocks in "eye candy" made absolutely no sense. I'm not saying at all that the old system was perfect or even good. What I am saying is that the new system is really bad and that the old system was *better*. I think simply renaming the categories in the old menu system for organizing applets and reorganizing which categories they fit into would have probably been all that was really needed (although I do think that panel-applets:// location would be cool too)

Clock is a good example where that might work but what about things like window list? This could be task list, application list, etc.

Well, that's true, but how does a hierarchy make this easier to find? If you don't know the name of an applet, you don't know the name. True, you might be able to narrow the search if you could go to a category but, again, only if you knew *which* category. I can think of at least five different categories the Window List applet could go into. I much prefer scrolling alphabetically to the handful or so possibilities and quickly glancing at the nice descriptions underneath the applet names.

Obviously there are more applications to be organized but the same engineering logic applies easily to either case.

That's the whole point. You can't have a flat list of applications because there are too many. If you only have five applications: gnumeric, abiword, gimp, inkscape, and evolution, it makes no sense to lump these into categories. It is just as easy to scroll down and pick the one you want. So how do you decide when you have too many to put in a flat list? I don't know, it could be 10 or it could 30. In this case I think the flat list is fine. If you were to add an additional 20 applets, though, then categorization would probably be necessary.

(although I do think that panel-applets:// location would be cool too)

I honestly think the Nautilus locations are overused and aren't very appropriate for a lot of things. If you were going to impose categories, I think a Treeview derivative of the current window would work better. Just scroll down and find your category, which should be associated with some descriptive text so you have an idea what is in that category, expand the branch, and select your applet.

I think its is better to work with a eindow then with a menu, but I agree that i should be at least categorized, labeled loke gmail or have a search field on the top.

Other cool feature whould be the possibility to drag a applet from the window to a panel.

The Add to Panel window already allows you to drag an applet to the panel, although why you would want to do this when there is an add button or you can just double click an item I don't know.

Direct manipulation, as in the HIG :)

>Other cool feature whould be the possibility to drag a applet from the window to a panel.
Ops, I remenber now, it is possible (sarcasm :P)

>*Other* cool feature whould be the possibility to drag a applet from the window to a panel.
This was a subject change.

The "(sarcasm)" was a joke on my own post, where, btw, I changed the subject a little (but keep talking about the applet add). You really don't have why insult me.
And this definitions post was not mine.

It was mentioned that there are way too many applets for the current view and I compleatelly agree with that. However, organizing all the stuff in menues is going to turn it into a huge mess and also would make it extremely hard for people to find what they are lookig for at first. So how about adding a search box that is hidden by default but you can display if you are looking for something and you have no idea where to find it? This would simplify greatly the matter as more and more applets appear and also the list of available options would be very small and searches would be really fast. However, haveing a search option would save you tons of time until you get to know all the options. Oh, yeah it might be also a good idea to search not just in the names of the applest but in their descriptions as well.

Adding a search box to the new applet-selection window would be The Right Thing. Just one search box, and it should search the name, the description, and any other available information, and filter the applets displayed. Just like the Epiphany bookmarks window, or album selection in Muine, actually. Menu hierarchies are the way of the past; fast ubiquitous searching is the way forward.

Menu hierarchies are the way of the past; fast ubiquitous searching is the way forward.

Is it? I don't really like having to switch between the mouse and keyboard all the time.

I'm still using epiphany 1.4 series and like the topic based bookmarks. But not having nested topics is really awkward if you have lots of bookmarks. I know it's coming in the new version (just waiting for debian packages).

If applets are grouped by topic (and an applet can be in multiple topics, and allow nested topics), then both user groups are happy. Either browse through a hierarchy of topics, or just hit search on a descriptive term.

The search ability makes a lot of sense and addresses scalability for the most part. In addition to searching on names and descriptions, it might be useful to add keywords to the applets for search purposes.

I do think that having the 'Add to Panel...' open up a nautilus view offers some interesting ideas. Allowing the user to choose from the standard nautilus view and sort options would be quite useful. The downside is that it seems a bit overkill to use nautilus for panel applet selection.

You could easily search on an applet's name, its categories, its description, etc. That sounds just like Evolution's VFolders. A brilliant solution. I hope somebody implements it.