[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]