OK, this is a bit weird. Fully updated, current Zen Mini installation. As you can see, the desktop file uses the "gksu -l gparted" command string. It works correctly if I launch GParted from the menu file More Applications>Configuration>GParted. However, if I use that command string within a terminal, I get an incorrect password error response.
[darrel@localhost ~]$ cat /usr/share/applications/gparted.desktop
_X-GNOME-FullName=GParted Partition Editor
Comment=Create, reorganize, and delete partitions
Exec=gksu -l gparted
Looking for gparted executable, I see there's one in /usr/bin and another one in /usr/sbin.
[darrel@localhost ~]$ ls -l /usr/sbin/gparted
-rwxr-xr-x 1 root root 2519 Feb 17 2011 /usr/sbin/gparted*
[darrel@localhost ~]$ ls -l /usr/bin/gparted
lrwxrwxrwx 1 root root 13 Jul 19 2011 /usr/bin/gparted -> consolehelper*
The odd thing is the the one in /usr/bin is soft linked to consolehelper. And, according to the (stock unaltered) system search path, /usr/bin is searched, but /usr/sbin is not.
[darrel@localhost ~]$ echo $PATH
If I enter "gparted" command string in a terminal, an error message comes up immediately saying the supplied password is incorrect, even though no password was requested or supplied. If, however, I enter "gksu -l /usr/sbin/gparted" command string in a terminal, the password requester comes up, and gparted launches after supplying root's password.
1. /usr/bin/gparted points to consolehelper.
2. /usr/sbin is not included in (my) user's search path, but probably should be.
3. The "gksu -l gparted" command string within the desktop file works here when GParted is launched from the menu, but the command string fails from the terminal. (It calls "gksu -l /usr/bin/gparted from my searchpath.) (Why does the desktop file work?)
4. The "gksu -l /usr/sbin/gparted" command string in a terminal works correctly.