[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 84616] New: write-protected files should not allow edits to
From:       Adrian Holovaty <kde () holovaty ! com>
Date:       2004-07-07 2:05:44
Message-ID: 20040707020544.25259.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
      
http://bugs.kde.org/show_bug.cgi?id=84616      
           Summary: write-protected files should not allow edits to ID3 tags
           Product: juk
           Version: unspecified
          Platform: RedHat RPMs
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: wheeler kde org
        ReportedBy: kde holovaty com


Version:           2.0.2 (using KDE KDE 3.2.3)
Installed from:    RedHat RPMs
OS:                Linux

I've noticed that if a sound file in Juk has read-only permissions, the "File name" field in the "Tag \
Editor" does not let the user rename the file -- i.e., the text field UI isn't even editable. That's a \
nice touch.

By the same logic, though, shouldn't changes to the other "Tag Editor" fields be disallowed? When I edit, \
say, the "Album name" field of a read-only file, it lets me make the edit, but when I click away (to save \
the change to the file), a "Could not save to specified file(s)" dialog box pops up.

In my opinion, the "Album name" and other fields should follow the same behavior as the "File name" field \
-- that is, they shouldn't be editable at *all* if the file is read-only.

As an aside, it also might be a good idea to gray-out all the metadata fields in read-only files, as an \
instant visual clue that they are not editable.


[prev in list] [next in list] [prev in thread] [next in thread]