Thanks to Nat, I have this picture of Joe Shaw on my phone, and I recommend you get one for yourself too

For GNOME Foundation Board of Directors

I’ve gotten some really good feedback from people, mostly in email about the menu stuff that I’ve posted. So here’s a little summary and some clarifications, because I think I wasn’t completely clear before and some of the responses have been way off what I’m looking to do.

The freedesktop.org desktop-entry-spec specifies that the .desktop files have the following format, using the Yelp project as an example:

Name=Yelp
GenericName=Help

With this specification you cannot produce an internationalized form of the of the menu entry, Yelp Help, or generically [Project Name] [Functional Name] – lets call this the PF format. In English the PF format obviously works, but we can’t be so pretentious as to assume that it works like that in all other languages, in fact it doesn’t. So even if we wanted to use the PF format we couldn’t conform to the f.d.o spec and have the translations make sense.

Currently, applications that want to use the PF format have to apply it to the name field, which goes against the f.d.o desktop entry spec recommendations. We’d like to keep our desktop entry files standardize to this spec as I’ve heard that Unix is a multi-user system.

What I’d like to see defined is how GNOME displays these desktop entries, not changing the desktop entries against the spec, changing the display so that our view of applications in core GNOME is more integrated and less like a bunch of 3rd party apps thrown together. There is room for the possibility of displaying things like this, but I think we need to work on this definition so that all the current desktop entry files conform to the standard and we have an elegant way of displaying them.

Shaun makes a good point that this might have odd effects on help pages.

Just to throw an idea out, maybe the doc system can be changed to use displayed name of the application instead of having it hard coded in the docs. If the doc system were grabbing the name of the application from the .desktop file (in the compile or install or during use) then it would always have the proper name and this might unload a lot of the doc teams time constantly having to chase the latest whim of how to rename everything on the desktop.

The idea has some holes, we might need to add something to the .desktop file so the docs know which name to grab and use, plus I’m sure there are a few other things that need work.

Anyway, I hope this clears up some of the issues, maybe not. I guess people can keep emailing me about it or catch me on IRC.

There has been quite a stir over the week about this and since it seem to have died down, I’ll try another explanation to stir the coals again. Here goes…

Generic Name

These are simply functional names and contain no other reference to the project it is under, company that makes it, or technology it uses. These names are the simplest for all users to understand as the name only contains the type of task the application is used to perform. An example of Generic Names would be Web Browser or Email and Calendaring

(Regular) Name

This name is the combination of the Project name and the functional name, the format looks like this: [Project Name] [Functional Name]. This style provides users with a brand *and* a name descriptive to the task the application was meant to be used for. The (Regular) Name is most helpful when there needs to be a differentiator between two applications with the same Generic Name. Of course having one application assume the Generic Name and another of the same type assume the (Regular) Name means they are different as well. Like having Web Browser and Firefox Web Browser.

Project Branding

Good project names are a great thing for each project to have. As there are always multiple applications of the same type out there, a project name provides a way to be different from the others. Project names also provide an easy way for developers to discuss the project, it provides a way to promote and defend the project as well. No one says Remember the Garrison in San Antonio, Texas that was defeated by the Mexicans in 1836, instead we say Remember the Alamo and everyone knows what we mean; the proper name has a lot of meaning which is good since there were thousands of Garrisons in Texas at that time. However since the Project name doesn’t really describe what the application actually does its completely useless to the uneducated, those who don’t have an American history background don’t know what happened at the Alamo. And users who don’t keep up with the latest in Free Software have no idea what the project names we use actually do, take Galeon for example. History buffs will have you believe you should know that the Alamo served as a rallying cry for defeating the Mexicans 46 days later, of course just knowing that it served as a rallying cry for Texas independence was always enough to get you by. Software buffs are the same way with Project names, we feel we need to make the users more educated in order for them to use the computer effectively, in reality people just want to get by with what is on the computer, not have a history lesson.

Forcing Your Brand

In the good old days of GNOME we didn’t have functional names displayed, we only had project names. People were forced to wander through the menus (Gimp, Galeon, Eog, Pan, GnuCash, etc.) and learn what each application did in order to find the one they wanted. Later on we evolved to conceding that this was a mess, since the project names didn’t tell people what the applications did GNOME decided that adding functional names would be a good idea (and it was). However we’re still forcing people to learn those project names as people debate the best way to present them in the launchers. Is it Galeon Web Browser or maybe Web Browser (Galeon)? Why do we force those names on people? We’re proud of our project, but wouldn’t you be prouder if people had a better experience with your application? They wouldn’t be wondering if this is the correct web browser to use or if it was some other app.

How the GNOME Desktop App names should behave

Applications in the GNOME Desktop release should display their Generic Name only, as these are the integrated Desktop applications which (hopefully) provides for an excellent user experience. When an application of the same type or same Generic Name is installed that new third party application uses the (Regular) Name style and the GNOME Desktop application continues to use the Generic Name. When a user switches their default application handler the GNOME Desktop app does not change its displayed name to conform to this switch. Each application keeps it’s name displayed as it was when first installed, the user has chosen a 3rd party application to be the default and and needed to know the Branded name in order to make this switch, so it makes more sense to leave it so they know what application to launch.

Fear

What happens when I install another app and now I get two Generic Name applications and can’t tell the difference between them?

Only applications that are a part of the GNOME Desktop should take the Generic Name in their launcher and title bar, when other applications due this it is a bug and yes it *is* confusing. Third party applications that are installed are not part of the GNOME Desktop and therefore should have their Product Name displayed to show that they are an addition to what GNOME already has.

But how will people find help under the Email and Calendaring program?

Help – Contents should bring up the Help Browser where it would display GNOME Email and Calendaring.

This Generic Name thing will be a mess with the interpolation of KDE and other docs!

Well they don’t actually interpolate right now, do they? Second, by calling it GNOME [Generic Name] in the docs we can differentiate ourselves from KDE with the GNOME brand. Will this wreak havoc with distributions branding GNOME as their own? They already handle this with GNOME Terminal, GOK, Eog, Volume Control, Ghostview, and many others.

We’ll never be able to tell what people are asking about when they ask about the Email program!

Are they running GNOME? Are they calling it Email or GNOME Email? It’s probably the included Email program they are using, if you’re still unsure ask them to go to the Help – About just to check.

No one will be able to find help on the web searching for Generic Name!

Yes, searching for the Generic Name won’t turn up many results on Google. But there are several solutions to this. One might be to put an option in the Help menu Search Help on the Web, this could take you to a URL that will have more info on searching or do a search for you.

So now we’re going to put GNOME in front of every app to brand it?

No, bad! That is silly and redundant and just not helpful at all. We’re trying to reduce branding on the core components not increase it in a different direction.

Loathing

I want to see the brand name of my applications so I know what I’m launching, instead of wondering which of the 5 web browsers I have installed will launch when I click Web Browser!

Ugh, you *do* know which web browser you have installed just by looking at them. You have Web Browser, Firefox Web Browser, Galeon Web Browser, Opera Web Browser, and Mozilla Web Browser. If you’re looking for Epiphany just get used to the fact that it’s the default, by being so web browser savvy (i.e. having 5 installed), it would be safe to assume that you know which one each browser really is.

Users will not be able to find these applications via the command line because they will be uneducated as to what the name of the application is!

Many distributions are using symbolic links to the applications so you could type web-browser on the command line to get the GNOME Web Browser launched.

A Solution to this?

As some have suggested I think a extra field in the .desktop file, call it X-GNOME-Blessed=true or whatever will indicate that this application is part of the GNOME Desktop and not a 3rd party application. The code can detect this field and display the application name properly. The title bar of the application should inherit this name from the .desktop file and I believe there is a function call being worked on to do this automatically.

Now I’m off to check out the Parade going by my apartment and then to a Yankees vs. Sox game tonight where I’m hoping to see David Ortiz kick the shit out of more of those damn New Yorkers.

I’ve been using the notibat battery monitor for a while now since xkahn was on #usability and asked for any recommendations with his app. I think I had one.

I have to say that I really love this program. It’s simple, there is a small indicator of AC power or battery power, the battery life is shown in 4 bars and of course a mouse over will get you a tooltip with more precise information on battery life. It’s small in terms of screen real estate, choosing the notification area would not have been what I would have recommended… however since we have no place for hotplug type applets to land it works for now.

Here’s the best interaction that this system provides above all else:

And it’s not that dialog which is good interaction ( it doesn’t actual conform to the HIG specs; *shrug* ), but the fact that if you plug in your battery while the dialog is running, it automatically disappears.like it was designed to do that!

Here’s the info for this app (author, source):

Benjamin Kahn xkahn@ximian.com

http://cvs.gnome.org/viewcvs/notibat/

Otherwise things like this happen and I spend the rest of my time figuring out how I can get a view from my apartment like this

Seth and I took some time a couple of days ago to put together some ideas for a new Connect To Server dialog. We sent the message out to the nautilus list, but for everyone else here’s a little mockup of the new dialog:

Full Screen Mode

I submitted my patch to metacity for the fullscreen mode system. It’s current iteration is a bit of a hack to metacity, as in there’s room for a more robust D-BUS service support.

The basic idea is that when Metacity gets the message from an app that it wants to go into full screen mode it sends a D-BUS signal. This signal can be intercepted by another app that then makes the decision to turn off the screensaver or other focus stealing applications.

The current listener I have is written in python and available here. This listener only works on a one-time basis as I really don’t think that these kinds of listeners should just be hanging around waiting to be used, instead we should have and xinet.d type ui-policy-manager that listens on the D-BUS wire and calls these types of programs based off the signal matching mechanisms that they register.

Update: This also turns off the GNOME-Typing Break monitor

It’s a pretty bad argument and I hate to say it; but this is what OS X and Windows do.

All is not lost.

It appears that the old server I was using has gone down permanently and my entire user directory was lost in the flames. I need to setup Planet COSI again, but I don’t really feel like working on that just yet.

This will be the location of my blog from now on, I’m going to try to pull down at least the entries from Advogato and place them all in here. I need to find that script that people had not too long ago.

This is still in the testing phase, so don’t expect to switch whatever you were doing over to this Blog Editor just yet. If you read the README included with the software you’ll see why I never intended for this to continue beyond what I have already, however I’ve had a lot of response from people asking for it to be done, so I’ll keep working on it slowly.

What’s new in this release:

A new home, http://www.gnome.org/~clarkbw/monkey-journal/

Better Parsing, most tags are handled very nicely now to give a lot cleaner HTML

Less code than before

What’s not happening:

Network progress support

Clean exception handling for better errors

Nice, understandable error dialogs