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.
CVS commit by mpyne: Fix bug 84616 by disabling the tag editor pane and the Edit... context-menu option when only one file is selected, and it's read-only. CCMAIL:84616-done@bugs.kde.org CCMAIL:wheeler@kde.org M +10 -0 playlist.cpp 1.230 M +4 -0 tageditor.cpp 1.65 --- kdemultimedia/juk/playlist.cpp #1.229:1.230 @@ -1664,4 +1664,14 @@ void Playlist::slotShowRMBMenu(QListView m_rmbMenu->setItemVisible(m_rmbEditID, showEdit); + // Disable edit menu if only one file is selected, and it's read-only + + QFileInfo fi(static_cast<PlaylistItem*>(item)->file().absFilePath()); + bool enableEdit = true; + + if(!fi.isWritable() && selectedItems().count() == 1) + enableEdit = false; + + m_rmbMenu->setItemEnabled(m_rmbEditID, enableEdit); + m_rmbMenu->popup(point); m_currentColumn = column; --- kdemultimedia/juk/tageditor.cpp #1.64:1.65 @@ -164,4 +164,8 @@ void TagEditor::slotRefresh() Tag *tag = item->file().tag(); + QFileInfo fi(item->file().absFilePath()); + if(!fi.isWritable() && m_items.count() == 1) + setEnabled(false); + m_artistNameBox->setEditText(tag->artist()); m_trackNameBox->setText(tag->title());