Bug 1313

I have started an Etherpad at http://trinity.etherpad.trinitydesktop.org/59 to help track compliance

The only XDG related comment I found at the provided link:

"The Trinity desktop environment (a KDE 3.5 fork) still doesn't seem to comply with the XDG icon naming spec and STILL shows an empty KControl window if you install it alongside KDE 4."

We can ignore the comment about the empty KControl. I have not read a valid bug report like that in a long time or any other report about such conflicts with KDE4.

Regarding the XDG naming, we need examples. The comment above provides no clue as to exactly what is not compliant.

With that said, seems the spec requires exact text strings in icon names. For example, "edit-clear." There are no such icon names in Trinity, which implies a ton of work involved to evaluate every single icon name.

If that is the case then we need a mini how-to to methodically evaluate and resolve every single icon name.

I don't think this is a trivial undertaking. :)

(In reply to comment #2)
> The only XDG related comment I found at the provided link:
> 
> "The Trinity desktop environment (a KDE 3.5 fork) still doesn't seem to comply
> with the XDG icon naming spec and STILL shows an empty KControl window if you
> install it alongside KDE 4."
> 
> We can ignore the comment about the empty KControl. I have not read a valid bug
> report like that in a long time or any other report about such conflicts with
> KDE4.

Agreed.  I have run into some of this XDG naming issue myself with the GTK3 theme engine, so I can assure you there is a valid issue here. :-)  How pervasive it is I am not sure.
 
> Regarding the XDG naming, we need examples. The comment above provides no clue
> as to exactly what is not compliant.

Most likely the icon names themselves, for example if the XDG specification requires an icon in the actions folder with the name foobar, TDE must provide a cr<nn>-action-foobar.png in the GIT tree somewhere, where <nn> is the pixel size (usually 16, 22, 32, 48, etc.)

> With that said, seems the spec requires exact text strings in icon names. For
> example, "edit-clear." There are no such icon names in Trinity, which implies a
> ton of work involved to evaluate every single icon name.
> 
> If that is the case then we need a mini how-to to methodically evaluate and
> resolve every single icon name.
> 
> I don't think this is a trivial undertaking. :)

I know, that's why this is an enhancement bug. :-)  Some kind of automated repair method is probably going to be required once we know where and how TDE is diverging, but initial inspection is unfortunately a manual undertaking.

To make matters worse, TDE tends to spread its icons around the core modules somewhat.  For example, PIM related actions are part of tdepim instead of tdelibs.

Tim

Once of our most egregious violations appears to be the use of the directory name "filesystems" instead of "places".  I need to look through the TDE code to figure out where filesystems is being referenced, but fixing this one issue alone will yield significant interoperability benefits with respect to KDE4/Gnome/XFCE.

Egregious? :)

We have to be careful not to perform a global search-and-replace. Typically when that happens, many text files, such as README, change logs, etc., are modified and we don't want to change those types of files. I don't think that can happen with this effort because I believe all changes are file name strings only.

We should post a nominal test plan. If certain problems are noticed with KDE4/Gnome/XFCE, we should log the suspected problem and later log the problem as resolved after patching. That is, for others to be involved, including myself, we need to know what we are fixing and not just blindly changing file names. We should be able to notice something being resolved with the file name changes. Just my 2 cents.

(In reply to comment #5)
> Egregious? :)
> 
> We have to be careful not to perform a global search-and-replace.

Definitely!

Repairing this one issue seems to be a (simple?) matter of modifying these two files to install the icons in the correct directory:
cmake/modules/TDEMacros.cmake
admin/am_edit

Getting TDE to recognise the new directory should then only require find/replace modification of the various index.theme files scattered throughout the GIT tree.  

It might also be a good idea to modify tdecore/kicontheme.cpp along with the index.theme files so that "Places" is used uniformly instead of "FileSystems"

I just pushed a handful of patches to move the directory location from filesystems to places.  There are still many missing icons compared to the XDG specification, but at least this is a start...

I see the "places" patches in the commits page, although the way the page updates I don't know whether all related patches have been committed. I'll resync my local repository and then start building packages.

This is something I'm concerned about. The main GIT branch is for development, but we should proceed smartly. That is, the GIT development branch needs to remain usable because using that branch is the only way we can find bugs and test. My concern is we submit patches for this bug report in a wholesale manner. I can't tell by the commit page, but looks like this happened for this first wave.

I expect bugs using the development branch but they should be easily resolvable if we first test patches locally and then push to GIT as a set.

This particular bug report requires patching multiple modules at a pass. That pretty much requires rebuilding package sets each time to properly test and debug. That means several hours to rebuild, which for me, usually means at night when I sleep.

My point is to test locally and push to GIT in a methodical manner so everybody else can test as efficiently as possible.

I have systems with GTK3 installed and not installed. Do we have a test plan for this first wave of "places" patches? What to look for? What to expect?

(In reply to comment #8)
> I see the "places" patches in the commits page, although the way the page
> updates I don't know whether all related patches have been committed. I'll
> resync my local repository and then start building packages.
> 
> This is something I'm concerned about. The main GIT branch is for development,
> but we should proceed smartly. That is, the GIT development branch needs to
> remain usable because using that branch is the only way we can find bugs and
> test. My concern is we submit patches for this bug report in a wholesale
> manner. I can't tell by the commit page, but looks like this happened for this
> first wave.
> 
> I expect bugs using the development branch but they should be easily resolvable
> if we first test patches locally and then push to GIT as a set.
> 
> This particular bug report requires patching multiple modules at a pass. That
> pretty much requires rebuilding package sets each time to properly test and
> debug. That means several hours to rebuild, which for me, usually means at
> night when I sleep.
> 
> My point is to test locally and push to GIT in a methodical manner so everybody
> else can test as efficiently as possible.
> 
> I have systems with GTK3 installed and not installed. Do we have a test plan
> for this first wave of "places" patches? What to look for? What to expect?

All of the "places" patches that should be needed are already in GIT.    What you should look for is:

Regressions: Look in Konqueror, the open/save dialogs, Dolphin, etc. to make sure that the folder/home/filesystem-related icons are still functioning normally (i.e. those applications are showing the same icons as before the patch).  Also ensure that changing the icon set actually changes the folder/home/filesystem-related icons in TDE applications

New functionality: Start a file manager or open/save dialog in GTK3 and see if the TDE icons are used to draw the folders and home button.

Conceptually this round of patches is very simple; I moved the obsolete Filesystem category of icons to the Places category which supersedes it.  This specification change was made over 7 years ago and was never fixed in KDE 3.5.x for some reason.

Tim

Okay, sounds good. Much of the same problems I saw when I made the XDG changes a few months ago. A challenge with watching for such anomalies is no user will use each and every app every day. Therefore some bugs might not be noticeable for days or weeks. Usually that means debugging is more challenging because of the time gap but in this case the problems all should be similar.

Nonetheless, I suggest we push patches for this bug report in a methodical manner. Allow GIT users/testers a week or two to notice unusual events and behavior before proceeding with the next wave of related patches.

Some Trinity user config files use hard-coded paths. Thus the solution likely will be a need to update the r14-xdg-update script. :)

How much work remains for this report? The related etherpad has not been updated in two months:

http://trinity.etherpad.trinitydesktop.org/60

(In reply to comment #11)
> How much work remains for this report? The related etherpad has not been
> updated in two months:
> 
> http://trinity.etherpad.trinitydesktop.org/60

Quite a bit of work, actually.  Creating the missing icons is one problem, but renaming the existing icons with wrong names will require careful work to avoid corrupting the TDE source tree as in previous renaming attempts.  Basically I got pulled off of this two months ago and nothing changed since. :-)

Hello, this bug is currently causing problems in openSUSE when KDE4 is installed.

In the TDE start menu, there are missing categories icons (there are surely other icons missing, but they are the most visible).

It looks like there is again a mixup between configuration files under /usr/share and files under /opt/trinity/share .

For example, I have the "Internet" top category icon not displayed in TDE.

I look at file:
  /usr/share/desktop-directories/kde-internet.directory
It says:
  Icon=applications-internet

I notice that the icon "applications-internet" exists under /usr/share but not under /opt/trinity.

I also have:
  /opt/trinity/share/desktop-directories/kde-internet.directory
It says:
  Icon=package_network

But this file is taken into account only if there is no equivalent file under /usr.

On my setup, I notice that $XDG_DATA_DIRS contain /usr/share:/opt/trinity/share .
Is it on purpose that "/usr" is before "/opt/trinity" ? Or is it again a case that we do not handle correctly in "startkde" ?

Francois, is your post still a problem?

Tim, would you please post a list of what needs to be done so others can start working on this?

Further, the web site About page claims Trinity is XDG compliant. This bug report claims otherwise. Fix the web site?

(In reply to comment #15)
> Tim, would you please post a list of what needs to be done so others can start
> working on this?

The Etherpad contains a correct and current status.  I haven't been able to touch this report since my last post above.

> Further, the web site About page claims Trinity is XDG compliant. This bug
> report claims otherwise. Fix the web site?

TDE is XDG compliant in every respect except the icon names.  I don't know if most desktops claiming to be XDG compliant are also compliant with the icon specification or not?

>The Etherpad contains a correct and current status.
Okay, I see the etherpads, although I don't yet know what all of the information means or how to proceed.

>TDE is XDG compliant in every respect except the icon names.
Okay.

(En réponse au commentaire 14)
> Francois, is your post still a problem?

No, this particular problem was solved as expected by fixing the XDG_DATA_DIRS variable in startkde script.

Still, I have some icons issues when using both KDE4 and TDE, which I believe are related to this bug.

On a fresh (new) user profile, I login in KDE4.
Some XDG directories (Download, Music, Videos ...) automatically get a nice icon.
Now, logout KDE4 and login in TDE: 
In konqueror, the same folders are lacking icon, nothing is displayed at all, not even the default folder icon.

>No, this particular problem was solved as expected by fixing the XDG_DATA_DIRS
>variable in startkde script.
Okay, glad to know. :)

>In konqueror, the same folders are lacking icon, nothing is displayed at all,
>not even the default folder icon.
I tried to replicate this but could not. I tried different View modes in konqueror and in the desktops I tested, KDE4, Trinity, and Xfce, I see icons for all of those folders in the respective file managers.

Quick update on this report.  Most of the core icons types have been converted to the XDG specifications at this point, with the largest unconverted categories being device icons, emoticons, and weather icons.  The remaining conversions should be easily handled via automation as the icon names are (mostly) unique.

*** Bug 2192 has been marked as a duplicate of this bug. ***

Two bugs:
---------

The actions/application-exit.png button on any TDE app toolbar is broken. Rather than display the expected red circle icon, the default 'Empty' icon displays, which I 'think' is now named mimetypes/application-vnd.tde.misc.png.

The TDE cache was flushed before starting TDE.

The Exit icon displays correctly in the Select Icon dialog.

When trying to rebuild a toolbar using the dialogs, the Quit action does not show an icon. Hence the 'Empty' icon.

I think the respective icon reference in any toolbar rc file was named file_quit. Modifying file_quit to application_exit or just exit and starting a respective app does not fix the icon in the toolbar.

This bug should be an R14 blocker.

-------------------

In the Select Icons dialog, Mimetypes drop-down category, the majority of the icon labels begin with "application-." There is no way to actually read the icon name.

(In reply to Darrell from comment #22)
> Two bugs:
> ---------
> 
> The actions/application-exit.png button on any TDE app toolbar is broken.
> Rather than display the expected red circle icon, the default 'Empty' icon
> displays, which I 'think' is now named
> mimetypes/application-vnd.tde.misc.png.
> 
> The TDE cache was flushed before starting TDE.
> 
> The Exit icon displays correctly in the Select Icon dialog.
> 
> When trying to rebuild a toolbar using the dialogs, the Quit action does not
> show an icon. Hence the 'Empty' icon.
> 
> I think the respective icon reference in any toolbar rc file was named
> file_quit. Modifying file_quit to application_exit or just exit and starting
> a respective app does not fix the icon in the toolbar.
> 
> This bug should be an R14 blocker.

That one snuck right past me; good catch!  Fixed in GIT hash 6209a28 (tdelibs).

> -------------------
> 
> In the Select Icons dialog, Mimetypes drop-down category, the majority of
> the icon labels begin with "application-." There is no way to actually read
> the icon name.

I'm not sure what to do about this issue.  On one hand we can't change the names as the XDG specification demands they start with "application-", but on the other hand the labels are unusable as you have stated.  Stripping off the "application-" part of the name isn't really an option either.  Increasing the number of lines of text displayed might be an option, but will de-emphasize the graphical selection matrix "feel" of the dialog.

Suggestions are welcome. :-)

Hi all,

Ideally, once TDE is iu to XDG icon compliance, it should be able to use the following icon theme without missing many icon:
http://kde-look.org/content/show.php/BreezeRemix?content=167712

Thank you!
-Alexandre

(In reply to Alex Couture from comment #24)
> Hi all,
> 
> Ideally, once TDE is iu to XDG icon compliance, it should be able to use the
> following icon theme without missing many icon:
> http://kde-look.org/content/show.php/BreezeRemix?content=167712
> 
> Thank you!
> -Alexandre

Just wanted to give you the heads up that, even once TDE is fully compilant (and it is very close now), there will still be some issues using non-TDE icon themes.  TDE supports so many more features than most other desktops that it uses many "extra" icons that are not part of the XDG specification.  As a result, those icons would continue to be provided by the default Crystal icon set.

Ok, good to know!

Yes, I know about the ''inherit'' feature provided by the index.theme file, in icons theme folders. It makes it possible to choose fallback icon themes, and the priority.

I understand that gnome(or others) does not have the same feature set, so its possible that some icons will fall back to Crystal, but there is still many icons missing in themes made for KDE4/Plasma Desktop.

I don't know if it is TDE who does not recognize many of those icons, or if KDE use non-standard icon names, but the BreezeRemix icon theme is certainly fairly complete on KDE4. So, what is the difference making it only partially complete on TDE? If you have some time to try it, you'll see what is missing.

Thank you!
-Alexandre