By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 2076

Summary: Desktop icon Properties dialog inconsistencies
Product: TDE Reporter: Darrell <darrella>
Component: tdelibsAssignee: Timothy Pearson <kb9vqf>
Status: NEW ---    
Severity: normal CC: bugwatch, darrella, kb9vqf
Priority: P5    
Version: R14.0.x [Trinity]   
Hardware: Other   
OS: Linux   
Compiler Version: TDE Version String:
Application Version: Application Name:
Attachments: Text file of gdb backtrace
Text file of gdb backtrace

Description Darrell 2014-07-14 18:28:17 CDT
From the menu "right-click" on "Personal Files (Home)" and select "Add Item to Desktop." A "Home" desktop icon appears on the desktop. The Properties dialog shows the correct icon. Then select the dialog icon button to modify the icon. The Select Icon dialog defaults to Applications rather than Places. I am not suggesting users should only be allowed to select icons from Places, only that Home is a Places icon and I expected the Select Icon dialog to default to the same icon type.

I have custom submenus in my main panel menu. When I selected one of the menus to add to the desktop the resulting desktop icon is a folder. The Properties dialog correctly showed a folder but the Select Icon dialog again defaulted to Applications.

"Right-click" on the desktop and from the popup menu selected "Create New -> Link to Location (URL)...." Select a folder. The desktop icon is not a folder but the Filenew icon.

"Right-click" on the desktop and from the popup menu selected "Create New -> Link to Device." Select a device. A dialog appears with the correct icon. Selecting the icon button results in the Select Icon dialog defaulting to Devices, which is expected. After the new icon appears on the desktop, select Properties from the popup menu and an error dialog appears:

---------------------------------------
Error - KDesktop
----------------
The desktop entry file
/home/${USER}/Desktop/DVD-ROM Device
is of type FSDevice but has no Dev= entry.

|OK|
---------------------------------------

The message is from tdelibs/tdeio/tdeio/kmimetype.cpp. After acknowledging the error dialog the popup menu appears. Unlike the previous examples, the dialog icon button correctly defaults to Devices rather than Applications.
Comment 1 Timothy Pearson 2014-07-15 13:49:30 CDT
Pretty sure the Link to Location problem is an old KDE bug from many years ago.  The other two look like regressions (or, more likely, rough edges in new R14 functionality).
Comment 2 Timothy Pearson 2014-07-21 12:58:43 CDT
(In reply to Darrell from comment #0)
> "Right-click" on the desktop and from the popup menu selected "Create New ->
> Link to Device." Select a device. A dialog appears with the correct icon.
> Selecting the icon button results in the Select Icon dialog defaulting to
> Devices, which is expected. After the new icon appears on the desktop,
> select Properties from the popup menu and an error dialog appears:
> 
> ---------------------------------------
> Error - KDesktop
> ----------------
> The desktop entry file
> /home/${USER}/Desktop/DVD-ROM Device
> is of type FSDevice but has no Dev= entry.
> 
> |OK|
> ---------------------------------------
> 
> The message is from tdelibs/tdeio/tdeio/kmimetype.cpp. After acknowledging
> the error dialog the popup menu appears. Unlike the previous examples, the
> dialog icon button correctly defaults to Devices rather than Applications.

I cannot replicate this problem.  Can you attach one of the "corrupted" desktop files for analysis?

Thanks!
Comment 3 Timothy Pearson 2014-07-21 13:00:33 CDT
(In reply to Timothy Pearson from comment #2)
> I cannot replicate this problem.  Can you attach one of the "corrupted"
> desktop files for analysis?
> 
> Thanks!

Ah, never mind.  It seems that the error shows up when right-clicking on a previously defined device link that was created without a device being selected in the drop-down list.  I'm thinking the correct fix would be to prevent selection of OK in the creation dialog if a device has not been selected.
Comment 4 Darrell 2014-07-21 13:24:03 CDT
Another related bug.

* Open konsole.
* tail -f ~/.xsession-errors.
* "Right-click" on the desktop.
* From the popup menu, select "Create New -> Link to Device."
* Select any device.

The following error appears in konsole:

kdesktop: WARNING: TDELocale: trying to look up "" in catalog. Fix the program.

Same error message described in bug 1989 and bug 1864.
Comment 5 Timothy Pearson 2014-07-24 10:45:26 CDT
(In reply to Timothy Pearson from comment #3)
> (In reply to Timothy Pearson from comment #2)
> > I cannot replicate this problem.  Can you attach one of the "corrupted"
> > desktop files for analysis?
> > 
> > Thanks!
> 
> Ah, never mind.  It seems that the error shows up when right-clicking on a
> previously defined device link that was created without a device being
> selected in the drop-down list.  I'm thinking the correct fix would be to
> prevent selection of OK in the creation dialog if a device has not been
> selected.

This issue was fixed in GIT hash e3db584.

(In reply to Darrell from comment #4)
> Another related bug.
> 
> * Open konsole.
> * tail -f ~/.xsession-errors.
> * "Right-click" on the desktop.
> * From the popup menu, select "Create New -> Link to Device."
> * Select any device.
> 
> The following error appears in konsole:
> 
> kdesktop: WARNING: TDELocale: trying to look up "" in catalog. Fix the
> program.
> 
> Same error message described in bug 1989 and bug 1864.

I am having difficulty replicating this part of the bug report.  Can you attach gdb to kdesktop (from Konsole, gdb --pid `pidof kdesktop`), insert a breakpoint at the offending line (b tdelocale.cpp:730), continue execution (c), then try to create the link to device?  When you do that kdesktop should freeze and you should be able to get a backtrace by typing 'bt' at the gdb prompt.  Posting that backtrace here will allow me to resolve the problem quickly.

Thanks!
Comment 6 Darrell 2014-07-24 15:10:47 CDT
Created attachment 2101 [details]
Text file of gdb backtrace

> Posting that backtrace here will allow me to resolve the problem quickly.
Attached.
Comment 7 Timothy Pearson 2014-07-24 21:21:54 CDT
(In reply to Darrell from comment #6)
> Created attachment 2101 [details]
> Text file of gdb backtrace
> 
> > Posting that backtrace here will allow me to resolve the problem quickly.
> Attached.

Thanks; this should be fixed in GIT hash 4bfc455.

If you can do something similar for the other reports they can be resolved pretty quickly as well.
Comment 8 Darrell 2014-07-25 00:12:45 CDT
I rebuilt tdelibs and tdebase. The "is of type FSDevice but has no Dev= entry" dialog looks resolved, but the TDELocale message persists.
Comment 9 Timothy Pearson 2014-07-25 10:57:18 CDT
(In reply to Darrell from comment #8)
> I rebuilt tdelibs and tdebase. The "is of type FSDevice but has no Dev=
> entry" dialog looks resolved, but the TDELocale message persists.

Odd, I thought I'd fixed that.  Can you re-run the backtrace for me with the new binaries?

Thanks!

Tim
Comment 10 Darrell 2014-07-25 12:55:43 CDT
Created attachment 2103 [details]
Text file of gdb backtrace

>Can you re-run the backtrace for me with the new binaries?
Second attachment.
Comment 11 Timothy Pearson 2014-07-25 22:11:02 CDT
(In reply to Darrell from comment #10)
> Created attachment 2103 [details]
> Text file of gdb backtrace
> 
> >Can you re-run the backtrace for me with the new binaries?
> Second attachment.

OK, the culprit changed location to tdeaddons.  I'll see what I can do.
Comment 12 Timothy Pearson 2014-07-25 22:29:34 CDT
(In reply to Timothy Pearson from comment #11)
> (In reply to Darrell from comment #10)
> > Created attachment 2103 [details]
> > Text file of gdb backtrace
> > 
> > >Can you re-run the backtrace for me with the new binaries?
> > Second attachment.
> 
> OK, the culprit changed location to tdeaddons.  I'll see what I can do.

Same problem, different file.  Fixed in tdeaddons GIT hash 744ba27.
Comment 13 Darrell 2014-07-26 12:54:54 CDT
> Same problem, different file.  Fixed in tdeaddons GIT hash 744ba27.
Looks good here. Thanks.

That leaves the two problems described in the first two paragraphs of the original problem description. Both examples might very well be the same bug.