Should be fixed in GIT hashes cbf8c41 (tdelibs) and d4f7d3e (tdebase).

Thanks for reporting!

Wow! Looks like some detailed patches. :-)

I had only three optical disk types here to test. My results:

Blank CD-RW
===========
Notification popup: "Medium type: Blank CD" <--- close enough?
Desktop icon: Devices: gold cdwriter unmounted
Desktop icon text: "Blank CD-RW"

Blank DL DVD+R
==============
Notification popup: "Medium type: Unknown" <--- Incorrect
Desktop icon: Mimetypes: "Empty" <--- Incorrect
Desktop icon  label: "Blank Dual Layer DVD+R"

Blank DL DVD+RW
===============
Notification popup: "Medium type: Unknown" <--- Incorrect
Desktop icon: Mimetypes: "Empty" <--- Incorrect
Desktop icon label: "Blank DVD+RW"

I notice when I select the desktop icon popup menu and then select Properties, the Properties dialog has a General tab and the button for the icon is a standard folder icon. When I click the button, the Select Icon dialog defaults to Places. I would have thought the Properties dialog would show the same icon as on the desktop and when selecting the button the Select Icon dialog would default to Devices rather than Places.

Note: the popup Medium type and desktop icons were incorrect before the latest patches. :-)

Note: the icons are incorrect in the popup dialog, the same incorrect mimetype icon as on the desktop.

Just a guess:

I suspect MOUNT_SUFFIX is not being defined correctly in tdebase/tdeioslave/media/mediamanager/tdehardwarebackend.cpp. I seem to remember this working in hal based systems (tdebase/tdeioslave/media/mediamanager/halbackend.cpp).

Not defining MOUNT_SUFFIX would leave the mimetype unknown, which would affect the labels and icons.

I would like to take a look at this bug, but how do I get the "Notification popup dialog" to appear when I insert a CD/DVD?

Edit or delete ~/.trinity/share/config/medianotifierrc if you have that particular popup disabled.

> Edit or delete ~/.trinity/share/config/medianotifierrc if you have that
> particular popup disabled.
Nope, doesn't seems to work. I had already tried also to change settings in Control Center -> Peripherals -> Storage media, which seems to go to the same file.
There must be some other option that I am missing, that's why I asked.

I don't know. Use a testing account with a frresh profile?

> I don't know. Use a testing account with a frresh profile?
Good idea.

As far as I can test, the problems affecting blank optical disks are resolved with commit 226c78e from bug 1371.

Commit 830ebe6f resolved the incorrect icon for DVDs.

The bug reported in comment 2 regarding the desktop icon Properties dialog is not resolved. The icon displayed in the Properties dialog is a folder rather than a device and is not the correct icon regardless of media type. Same results with a fresh profile. The problem seems to be that the dialog is defaulting to Places rather than actually looking at the mimetype. The bug affects other removable media, such as USB flash drives.

(In reply to Darrell from comment #11)
> As far as I can test, the problems affecting blank optical disks are
> resolved with commit 226c78e from bug 1371.
> 
> Commit 830ebe6f resolved the incorrect icon for DVDs.
> 
> The bug reported in comment 2 regarding the desktop icon Properties dialog
> is not resolved. The icon displayed in the Properties dialog is a folder
> rather than a device and is not the correct icon regardless of media type.
> Same results with a fresh profile. The problem seems to be that the dialog
> is defaulting to Places rather than actually looking at the mimetype. The
> bug affects other removable media, such as USB flash drives.

Confirming that the problem with the device icons also appears in Konqueror, thus hinting at a problem within the media:/ tdeioslave.

(In reply to Timothy Pearson from comment #12)
> (In reply to Darrell from comment #11)
> > As far as I can test, the problems affecting blank optical disks are
> > resolved with commit 226c78e from bug 1371.
> > 
> > Commit 830ebe6f resolved the incorrect icon for DVDs.
> > 
> > The bug reported in comment 2 regarding the desktop icon Properties dialog
> > is not resolved. The icon displayed in the Properties dialog is a folder
> > rather than a device and is not the correct icon regardless of media type.
> > Same results with a fresh profile. The problem seems to be that the dialog
> > is defaulting to Places rather than actually looking at the mimetype. The
> > bug affects other removable media, such as USB flash drives.
> 
> Confirming that the problem with the device icons also appears in Konqueror,
> thus hinting at a problem within the media:/ tdeioslave.

This should now be fixed in tdelibs GIT hash 5a3c9e4.  Please test and report back.

Thanks!

The patch seems to work for the device use cases previously described.

One noticeable difference is the Properties dialog now no longer allows a user to modify the icon. I suppose that makes sense for removable device icons but I don't know whether that was the intent of the patch.

I saw the same unchangeable icons for the special desktop icons (My Computer, My Documents, etc.).

(In reply to Darrell from comment #14)
> The patch seems to work for the device use cases previously described.
> 
> One noticeable difference is the Properties dialog now no longer allows a
> user to modify the icon. I suppose that makes sense for removable device
> icons but I don't know whether that was the intent of the patch.
> 
> I saw the same unchangeable icons for the special desktop icons (My
> Computer, My Documents, etc.).

That was the intent.  When I tried modifying the icons it didn't even work, so I just disabled the UI control for it.  Had TDE ever actually allowed you to modify the device icons via that method?

I see you filed a report for the other unchangeable icons.  Can we close this report out then?

Thanks!

>Had TDE ever actually allowed you to modify the device icons via that method?
Yes.

>I see you filed a report for the other unchangeable icons.
Yes. Discovered during my testing but not directly related.

>Can we close this report out then?
Yes.

(In reply to Darrell from comment #16)
> >Had TDE ever actually allowed you to modify the device icons via that method?
> Yes.

R14 did?  If so then I may have accidentally introduced a regression.  Was it only certain device types (e.g. Flash drives) or all devices that this worked on?

Thanks!

>Was it only certain device types (e.g. Flash drives) or all devices that this
>worked on?
All. I have another system with a package set from a few weeks ago. The icon button is available in that system.

(In reply to Darrell from comment #18)
> >Was it only certain device types (e.g. Flash drives) or all devices that this
> >worked on?
> All. I have another system with a package set from a few weeks ago. The icon
> button is available in that system.

All right, then I guess I introduced a regression.  Reopening until I can commit a proper fix.

(In reply to Timothy Pearson from comment #19)
> (In reply to Darrell from comment #18)
> > >Was it only certain device types (e.g. Flash drives) or all devices that this
> > >worked on?
> > All. I have another system with a package set from a few weeks ago. The icon
> > button is available in that system.
> 
> All right, then I guess I introduced a regression.  Reopening until I can
> commit a proper fix.

I just tried to change the icon on my Flash drive with commit 5a3c9e4 reversed.  While there were no errors in the dialog and the .directory file was created successfully, the icon on the desktop and in Konqueror did not change.  Just to confirm, you saw the device icon change in Konqueror to your user-defined icon when you performed this action?

Thanks!

Sorry for the confusion. I never tried changing a device icon. I only noticed that the pre-patched Properties dialog contained a changeable icon button, whereas the patched dialog does not. I mentioned in my testing comment that this made sense.

I performed the same test as you and even when the changeable button is available, the icon on the desktop and in konqueror do not change. Oddly, the icon in the Properties dialog does change and retains the change.

I am okay with the patch as-is with the changeable icon button removed.

That said, I notice some other results.

On a system with the patch reversed and a changeable icon button, the dialog retains the selected icon despite the desktop and konqueror not changing. Very strange looking. With the patch that would/could not happen because the icon is not changeable. The Properties dialog icon will be retained through a .directory file created on the USB flash drive. With the patch the creation of the .directory file should not be possible but without the patch the mixed result is weird.

Keeping the patch as-is is fine, but these tests trigger three stderr message reported in bug 1713, bug 1725, and bug 1718.

To trigger the bug 1713 stderr message, follow the steps shared in that bug report.

To trigger the bug 1725 stderr message, follow the steps shared in that bug report.

To trigger the bug 1718 stderr message:

* Use a desktop with the patch reversed.
* Remove the USB flash drive .directory file.
* Safely remove the USB device.
* Log out of Trinity.
* Delete the user's tdesycoca cache files.
* Log in to Trinity.
* Open konsole.
* tail -f ~/.xsession-errors.
* Insert the USB flash drive.
* Open the desktop icon Properties dialog.
* Change the icon.
* Select the dialog OK button.

Recommendations: Leave the patch as-is and this bug report RESOLVED. Use the reversed patch and the previous information to resolve the other bug reports.

Sounds good to me.  I'll take a look at the related device icons bug report (Bug 2076) shortly.

Tim