Hello!
PCMan has written on Friday, 28 June, at 11:38:
>On Fri, Jun 28, 2013 at 6:48 AM, Andrej N. Gritsenko <[email protected]>
>wrote:
>> I've found a little inconvenience in the FmPathEntry behavior. When
>> you are in menu://applications/ folder and you go into some folder then
>> you get not into the folder where you come but into another. For example,
>> if I go into "Стандартні", I come not into menu://applications/Стандартні
>> but into menu://applications/Accessories instead. And situation if you
>> going into Applications come into Tools but going into Tools end up in
>> the Applications is completely valid (you know, folder names may be any).
>> It is just because path entry never shows display name (i.e. the name
>> which is shown in view) but some modification of the path name instead.
>> I'm not sure if that behavior is right one. The most probably the path
>> entry should show the same name which is shown in the view, therefore
>> going from main menu folder into Wine -> Programs should bring you into
>> folder menu://applications/Wine/Programs instead of another path which
>> isn't so clear - menu://applications/wine-wine/wine-Programs - which is
>> shown right now. I know, menu://applications/wine-wine/wine-Programs is
>> internal path representation in XDG menu specification, but does every
>> user knows that? It probably will confuse some. And I believe that menu
>> isn't unique in that and some other VFS may give similar results.
>> What do you think? Should that be changed or let it stay as it is?
>We need to leave it as it is and there're no other good options ATM.
>It's perfectly legal in the XDG spec for two categories to have the
>same display name.
>So it's better to use the internal name here. Otherwise there will be
>ambiguity.
What I meant is that the path entry is completely unusable for the
Application folder and subfolders. Yes, is may contain similar items in
case of English language (Education, Games, Graphics, Internet, Office,
Development) but many items if you type its name in path bar will end up
in the error message about invalid directory. And that is even worse in
case of some language other than English - anything you type in the path
entry will result in invalid directory and you cannot even think about
autocompletion since you don't know what you have to type to go into some
directory such as DesktopSettings even in English (it is displayed as
"Preferences" and typing 'P' will give you NO matches). Therefore since
the path entry is completely unusable the only way to navigate inside of
Application folder is mouse or cursor keys. Is it intended behavior?
I understand that any two menu items (be it directory or application)
may have the same display name but it will be ambiguity in any case and
the user will rename one of them in such case (and also file a bugreport
for the package). To have two identical directories in the menu tree is a
big annoyance for user so mentioned issue (ambiguous chdir) will be never
reached. So I see no real problem.
>Another option is showing the display path in the entry.
>When the entry gets focus, show the internal path instead.
>This might look weird, though.
How that would help? It even more weird than it is now. Less weird
might be opposite I think but I see no reasons to change content of the
path bar when it gets focus. It is inappropriate and lead to confuse, not
mention resources consumption for that. :)
Cheers.
Andriy.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Pcmanfm-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
