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