On Sat, Jun 29, 2013 at 2:52 AM, Andrej N. Gritsenko <[email protected]> wrote: > 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. OK, agree! The only thing that needs to be fix is the directory enumerator of the menu vfs. But seriously, who will use the path entry to nagivate the application menu? I see no real use case here and I'm very reluctant to add this complexity to the vfs. The purpose of presenting the menu as a folder is just a convenient feature. Most people I believe will use the application menu in the panel. Do you know anyone who use the application menu via typing the paths in that entry? Another problem your proposal will introduce is valid. The path, if composed of display name, will become locale dependent. If you login with a different locale, which is possible, the path changes. That means, if you have a desktop entry file which refers to this path, it will become broken. When I add the menu:// support in the past, what I've in mind is actually more than an application menu. Showing menu://appliations/DesktopSettings, for example, is just like a "Control center". Or we can add a specific menu file for the control center like /etc/xdg/menus/settings.menu in gnome. So we can access all configuration tool by navigating menu://settings/. That's why a locale independent path is needed. Otherwise desktop entry files referencing it will be broken. Unless you support both forms of paths, and convert internal paths to display name-based paths. This is possible and can be done in fm_path_display_name(). What do you think? We still support the internal path, but convert it to display path automatically and show the display path in the path entry by default.
Thanks ------------------------------------------------------------------------------ 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
