From: Andrej N. G. <an...@re...> - 2013-06-28 18:52:41
|
Hello! PCMan has written on Friday, 28 June, at 11:38: >On Fri, Jun 28, 2013 at 6:48 AM, Andrej N. Gritsenko <an...@re...> 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. |