Hello!
PCMan has written on Saturday, 29 June, at 11:18:
>On Sat, Jun 29, 2013 at 2:52 AM, Andrej N. Gritsenko <[email protected]>
>wrote:
>> 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.
It is not enumerator which should be changed but handler of the call
g_file_get_child_for_display_name() in there. But really I have to create
some parts of related code in any case to support renaming and mentioned
handler will easily come as a side effect too. :)
>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.
This will not require adding any complexity to the VFS, it will
require fix on FmPath handling display name which is in fact incorrect
now (it is oriented to single charset native path and nothing else is
possible).
>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.
That is a good point. But what I propose really is use display names
for path elements _just_ in path entry. For commandline arguments and for
shortcuts the "real path" (i.e. an internal representation) will be still
used so nothing mentioned becomes broken.
And you've reminded me that creating shortcuts isn't implemented in
libfm yet. It works if we create symlink but you know symlinks can be
created only from native path to native path, in any other case we have
to create shortcut (desktop entry with Type=Link) instead. Thank you for
the reminding, added that to TODO list. :)
>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.
Exactly what I have in mind and I even have it partially implemented
already. As soon we merge vfs-menu-fileops into master, I create the new
branch with those changes and we can discuss the implementation. It is
relatively simple and touches mostly fm_path*_display_*() APIs (as I said
above, they should be corrected anyway).
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
