Is it wrong to use the hand cursor for clickable items such as buttons?

I've always thought the hand cursor to be the ideal visual indicator for "you may click here" to the user. We are used to see it in this context daily because of it's usage on hyperlinks and hence all web buttons.

                 

However, most desktop applications seem to keep the defeault pointer arrow for buttons.

                                 

I really feel better when buttons, and other clickable items such as checkboxes and radio buttons use the hand cursor. Somehow, I find it personally pleasing to see this cursor when I hover over clickable items, maybe because it's consistent with how webpages and even many games do it.

But as developers, We have to think of the children user and sometimes do things not as we like them but as the user likes them. Problem is, I feel so fuzzy about the hand cursor on buttons that I'm blind to the possibility of it being inappropriate. Many design mistakes are caused by such personal decisions.

                                      

What do you think about it?

Edit: Recently I've taken notice of usage of the hand cursor on Photoshop (CS3 on XP), but probably only because I was using it more extensively. Screenshot:

                                         

Do note that many of the places where the hand was used are obviously clickable.
EDIT2: Do also note that they've even used a custom cursor, which to be honest I'd never do, especially for something trivial as a hand cursor that's so ubiquitous. And it's not even pretty.

The reason why the cursor changes shape when over a hyperlink probably has to do with the following:

• hyperlinks started in blocks of text and as such it wasn't obvious that you could click on them to open another page.
• the change in display style for links in and of itself probably wasn't enough to communicate the "clickability" of a link. Possibly also because the changes in display style aren't exactly standardised, while the handshape cursor is.
• buttons on web pages used to be "normally" clickable I think though I can't remember whether they caused the cursor to change shape. Nowadays "buttons" are often "faked" using css and you need some other way to tell the user they can click on it => handshape cursor has become the default for that.

All of the above however is geared towards communicating "clickablity" within the content of a webpage. Buttons, buttons on toolbars, menu items etc have always been clickable without changing the shape of the cursor. And you don't see browsers changing the shape of the cursor either when you are hovering over a menu item or toolbar button.

In a desktop application you probably wouldn't change the cursor over every item in a tree even if that brings up different information in a panel to the side of the tree? Or for every item you can select in a listbox? Or for the radiobuttons or checkboxes on a form? So why do it for form buttons which in a desktop application have always been easy to identify and are clickable by nature.

I wouldn't change the cursor shape for anything in a desktop application that is (has always been understood to be) "clickable by nature". I would only use "web-like" cursor shapes when displaying information in a "web-like" manner. For example clickable parts of text in a grid in which the text is not normally clickable. Otherwise I'd stick with the standard cursor shapes. It also helps to keep down the "noise" in the user interface.

---

update in response to comment(s)

@Camilo: I get your "command" vs "selection" distinction. I would even add "navigation" to that mix. However, I still don't see the need to change cursor shapes on a command ui-element.

The distinction between navigation and command may get somewhat blurred if you think of them both simply as responses to user actions. To me there is a clear distinction between the two. Navigation are all actions to open forms, select items, etc. In general just rummage around... Commands are all actions that cause data to change, cause notifications (mail, messages of any kind) to be sent, or where the initiated action may take a longer than a second or two (establishing a connection, filtering a large dataset).

Loosely: if you would submit a form on the web using a "POST" (or "DELETE"), it would probably be a command, whereas anything else would be navigation.

Anyway, one thing I would never do is have a ui-element that is naturally more geared towards navigation and selection (like a treeview) execute a command. So where clicking on a treeview item will probably change the contents of some other part of the user interface, in my apps it would never for example initiate a payment...

As such, a tree of possible servers to connect to, to me is still a selection element. I would hope the actual connection is not made on a single click, but only when an item is double-clicked or after an item has been selected when a "connect" button is clicked. And therefore, in this particular case, I still wouldn't use a handshaped cursor on the tree.