#848 Desktop files can't be renamed with the context menu

1.3
open-later
pcmanfm (129)
4
2014-03-12
2014-03-10
Sworddragon
No

I'm using PCManFM 1.2.0 and have noticed that the context menu on valid desktop files doesn't contain an entry for renaming anymore.

Discussion

  • Lonely Stranger

    Lonely Stranger - 2014-03-10
    • labels: --> libfm
    • status: open --> closed-wont-fix
    • assigned_to: Lonely Stranger
     
  • Lonely Stranger

    Lonely Stranger - 2014-03-10

    Thank you very much for reporting that.

    I should admit that renaming of desktop entry files such as applications and shortcuts never worked despite the option was available in the context menu. I could not make it work otherwise than from properties dialog, that is limitation of GIO and to make a workaround on that only way is to open properties dialog on both "Rename" and "Properties" but I'm not sure if that is sane solution, it's why it is not present there now. You can use "Properties" still. I'm sorry. Feel free to suggest any other solution.

     
    Last edit: Lonely Stranger 2014-03-10
  • Sworddragon

    Sworddragon - 2014-03-11

    This is strange as it has always worked for me in 1.1.2 and earlier versions. If I have renamed a desktop file the filesystem name got successfully changed while the desktop name kept untouched. This is also the behavior I would expect there.

    Or wanted you to try to rename the desktop name instead of the filesystem name? I have this assumption as desktop files can still be renamed with the menu bar (it reads the desktop name but writes to the filesystem name). In this case maybe desktop files can have 2 renaming options. At least I would like if we could have the old option from PCManFM <= 1.1.2 back.

     
    Last edit: Sworddragon 2014-03-11
  • Lonely Stranger

    Lonely Stranger - 2014-03-11
    • labels: libfm --> pcmanfm
    • status: closed-wont-fix --> closed-fixed
     
  • Lonely Stranger

    Lonely Stranger - 2014-03-11

    Oh! Good point! That option should be inactive in menu too if file name cannot be changed. I've fixed this in GIT. Thank you very much!

    The changing filesytem name blindly (notice that!) from not shown to another not shown which may create a problem (there was a bugreport on that problem BTW) is invalid operation for shortcuts therefore should be unavailable - neither from context menu nor from main menu.

     
  • Lonely Stranger

    Lonely Stranger - 2014-03-11

    As I said earlier, you are welcome to suggest any other solution on issue. Thanks.

     
  • Sworddragon

    Sworddragon - 2014-03-11

    The changing filesytem name blindly (notice that!) from not shown to another not shown which may create a problem (there was a bugreport on that problem BTW)

    Yes, we don't see the filesystem name before and after the renaming but this should not be an obstacle for a renaming option.

    is invalid operation for shortcuts therefore should be unavailable

    Invalid, does this come from a specification? If yes, this makes no sense as it must be possible to rename desktop files somehow with a filemanager (ls from the GNU coreutils does show the filesystem name but it is not a filemanager). In PCManFM <= 1.1.2 we could rename desktop files even if it was more or less blindly (except that we could see the filesystem name on renaming). Now we can't do anything anymore.

     
  • Lonely Stranger

    Lonely Stranger - 2014-03-11

    It is invalid because it changes something that you cannot control and that change may create problems (many applications strictly depends on file name suffix ".desktop" but you may and will drop it blindly). Any uncontrollable behavior is invalid de facto so have uncontrollable behavior in pcmanfm is a bug and any bug will be fixed as soon it is discovered. Don't ask me to return a bug back into code, I will not do that.

    Well, can you give me any valid reason and use case where renaming of such kind might be required? I see no reason except if you open some terminal emulator but in that case you can rename it in that terminal emulator session. Why you may want to change something you never see and never use? The reason "just to test" is not valid one, I'm sorry. And in some rare cases changing of filesystem name is not possible at all (smb:// file system for example). But I agree, there should be an alternate way to change name which we see (displayable) for shortcuts which is available only in Properties dialog now, and I'm still open for your suggestions as I said.

     
  • Sworddragon

    Sworddragon - 2014-03-11

    It is invalid because it changes something that you cannot control and that change may create problems (many applications strictly depends on file name suffix ".desktop" but you may and will drop it blindly).

    I have often renamed .desktop files with PCManFM <= 1.1.2 and it has never dropped the .desktop file extension.

    Any uncontrollable behavior is invalid de facto so have uncontrollable behavior in pcmanfm is a bug and any bug will be fixed as soon it is discovered. Don't ask me to return a bug back into code, I will not do that.

    I don't want have bugs integrated too but I don't see any bug here. Maybe you can be more specific about the bug as I have never noticed one and all worked as I would expect it.

    Well, can you give me any valid reason and use case where renaming of such kind might be required?

    As developer I simply need the ability to rename desktop files. Currently I'm using the terminal to do this but this should not be the goal.

     
  • Lonely Stranger

    Lonely Stranger - 2014-03-12

    The bug is that filename should never be used for renaming. If you don't believe me then read GLib/GIO documentation - only utf-8 (displayable) name should be used and then GLib/GIO will convert it into right form, there were some bugreports about that problem (if I remember well you also reported some). The difference with shortcut is filesystem and displayable names are not correlated at all and GIO does not handle this case. And as soon LibFM/PCManFM uses the standard way (displayable name) for renaming, the old implementation cannot work since it will make a mess between those names. Have a Rename option which does not rename file (well, it might change filesystem name but user will never see that) is clearly a bug for any regular user (except for user who knows and uses this bug but you know, even used bug is still a bug).

    Well, GUI file managers are designed for users, developers fairly often use non-GUI file managers such as Midnight Commander - such FM is much more convenient for developer due to much more discrete access. But aside of that if you need more lowlevel access in PCManFM then it should be implemented differently - for example, as extra context menu option (Change Filesystem Name), becoming available with advanced_mode=1. If you want this then create a feature request against next release, please.

     
  • Lonely Stranger

    Lonely Stranger - 2014-03-12
    • status: closed-fixed --> open-later
    • Group: 1.2 --> 1.3
    • Priority: 5 --> 4
     
  • Sworddragon

    Sworddragon - 2014-03-12

    The bug is that filename should never be used for renaming. If you don't believe me then read GLib/GIO documentation - only utf-8 (displayable) name should be used and then GLib/GIO will convert it into right form, there were some bugreports about that problem (if I remember well you also reported some).

    Ah, this makes now sense (but I don't remember do have reported such an issue).

    Have a Rename option which does not rename file (well, it might change filesystem name but user will never see that) is clearly a bug for any regular user

    Yes, the user would think PCManFM is bugged here.

    But as you suggested I will open now a feature request for this.

     


Anonymous

Cancel  Add attachments