The tutorial should include instructions for packagers to install the tde.desktop session file in the respective directories of other login managers.

Is there any hope with this of getting trinity apps to work in a ssh -X tunnelled envvironment?

>Is there any hope with this of getting trinity apps to work in a ssh -X
>tunnelled environment?

I hope so. Would you please provide detailed steps how this fails for you? Include information about desktops being used in client side, server side, distro used, whether /etc/profile.d exists, etc.

Client and server sides Debian Wheezy installed through the network-install cd and seeded with a list of packages. i.e. NOT tde-trinity.

R14 ppa is in the list of apt sources.

Tdm is the X session manager on both machines.

/etc/profile.d exists but only contains bash_completion.sh script.

Path on the sloginned session does not include /opt/trinity/bin and none of the XDG or TDE environment variables are set.

Client and server sides Debian Wheezy installed through the network-install cd and seeded with a list of packages. i.e. NOT tde-trinity.

R14 ppa is in the list of apt sources.

Tdm is the X session manager on both machines.

/etc/profile.d exists but only contains bash_completion.sh script.

Path on the sloginned session does not include /opt/trinity/bin and none of the XDG or TDE environment variables are set.

It's not critical. It's major.

>It's not critical. It's major.
It needs to be fixed.

> It needs to be fixed.

As all major bugs!

If this bug report ever receives attention, I hope the topic of full renaming is discussed. One reason for complete renaming is Trinity no longer would need to be treated like a black sheep with always being installed in /opt.

The Mate project folks have done this. The renaming does not have to magical. For example, change konsole or kate to trinity-konsole and trinity-kate, or tde-konsole and tde-kate. As most users launch apps through the menu, they would barely notice the renaming. The Mate folks have done this with many of their files, although I believe the motivating reason was the original apps all were named gnome-*. Nonetheless, such a renaming scheme would allow Trinity to rejoin /usr land.

I am aware of the amount of work and testing required, but complete renaming seems a sane long-term decision.

Based on GTK2, Mate is snappy on older hardware. The project is gaining momentum, is supported in most distros, and will only grow in popularity. Moreso, Mate does not have $PATH or $XDG_DATA_DIR problems because everything is installed in /usr.

The reason this report has not received much attention is that it depends on a full renaming as you have mentioned.  There are some serious problems with this, even though it is a good long-term strategy.  For example, what to call Konsole?  Tonsole?  I don't think so. :-)

Also, you should see some of the flak I have been getting for years regarding the renaming I have done to just the user-invisible libraries.  Some of it borders on hate mail.  Naturally I am a bit tired of this and would like someone else to pick up the torch on the renaming project for a while.

At minimum, we need an Etherpad mapping old names to new names, as many of the names will need to be completely re-imagined.  The binary "namespace" of most distributions is quite crowded and it will be hard to avoid stepping on other applications.

>For example, what to call Konsole?  Tonsole?  I don't think so.
>The binary "namespace" of most distributions is quite crowded
As I mentioned, the mate folks use a simple 'mate' prefix. That would be an option for Trinity. Using a 'tde-' prefix would avoid conflicts.

I am not arguing. Just conversing. The fact that Trinity is forced to live in /opt rather than /usr is going to hurt. I saw at least one review where the reviewer could not run apps from the command line or launcher because $PATH was not configured correctly.

(In reply to Darrell from comment #11)
> >For example, what to call Konsole?  Tonsole?  I don't think so.
> >The binary "namespace" of most distributions is quite crowded
> As I mentioned, the mate folks use a simple 'mate' prefix. That would be an
> option for Trinity. Using a 'tde-' prefix would avoid conflicts.

Interesting, I did not know that!  If it is actually working for them then we might be able to do the same.

If we do this, would a suffix or a prefix be more desirable?  I'm leaning toward a suffix personally, but I'd like to hear others' opinions.

(In reply to Timothy Pearson from comment #12)
> > As I mentioned, the mate folks use a simple 'mate' prefix. That would be an
> > option for Trinity. Using a 'tde-' prefix would avoid conflicts.
> 
> Interesting, I did not know that!  If it is actually working for them then
> we might be able to do the same.

Upon re-reading this report I see the mention of the -mate suffix in your response.  Sorry for overlooking that.

Would -tde or-trinity be better?

Tim

They use a 'mate-' PREFIX, not suffix. I believe they do that partly out of renaming apps from the GNOME 2 days, as Mate is a fork/spin-off from GNOME 2 and partly because some apps retain the gnome-* prefix. Such as gnome-terminal, which is still used in GNOME 3.

To me a prefix makes more sense. 'tde' is shorter to type than 'trinity'. Typing tde-konsole will require some adjustment by long-time users, but as long as the bugs are fully repaired before release nobody will have anything to complain about. Anybody who has made menu or launcher shortcuts would have to update, but our r14-xdg-update script would include all of that. Any effort to rename in this manner needs a check list for each bin file to ensure r14-xdg-update is updated.

To remain consistent, share/apps and share/config files should be renamed the same.

A potential mess and a lot of work but living in /opt is not sane or healthy.

We could modify the TDE launcher to infer a tde- prefix if a.) the user did not put a tde- prefix on the front and b.) a tde-* executable exists by that name.  That should alleviate much of the problems with long-term users' finger memory (myself included).  Does this seem sane?

Could be bothersome when users want to mix Trinity and KDE apps. I don't use KDE apps in Trinity except for quick comparison testing, but who knows, some folks might. The apps in KDE that have no Trinity counterpart would not be affected. I am thinking best to not presume and not have the launcher do that.

We threw a lot of effort into the r14-xdg-update script but with a full scale renaming I suspect the script would become unwieldly. After a full scale rename we might have to tell users to just start with a new profile. Not a great move but not unprecedented. Then again, perhaps all files in share/apps and share/config don't have to be renamed.

Whenever we move forward with this bug report, we should first get the R14 bug list out of the way. Then freeze everything and tell GIT users to grab the last set of packages created before the freeze. If we keep three or four folks actively working, then we could finish in a few weeks. But not at the pace we've been going.

(In reply to Darrell from comment #16)
> Could be bothersome when users want to mix Trinity and KDE apps. I don't use
> KDE apps in Trinity except for quick comparison testing, but who knows, some
> folks might. The apps in KDE that have no Trinity counterpart would not be
> affected. I am thinking best to not presume and not have the launcher do
> that.

Or an option could be provided to turn it off.  In either case, I'm still leaning towards a suffix as typing "tde-" all the time will get old very fast--at least with a suffix, tab completion will do that for me.

> We threw a lot of effort into the r14-xdg-update script but with a full
> scale renaming I suspect the script would become unwieldly. After a full
> scale rename we might have to tell users to just start with a new profile.
> Not a great move but not unprecedented. Then again, perhaps all files in
> share/apps and share/config don't have to be renamed.

I don't think we have to rename anything that doesn't end up in /usr/bin or /usr/lib.  By using the tde suffix or prefix we've made our intention quite clear--the application's official name is the same as before.

> Whenever we move forward with this bug report, we should first get the R14
> bug list out of the way. Then freeze everything and tell GIT users to grab
> the last set of packages created before the freeze. If we keep three or four
> folks actively working, then we could finish in a few weeks. But not at the
> pace we've been going.

I agree that our pace is terrible.  I've been out of the loop for too long myself; I hope to fix that soon but I cannot guarantee anything at this time.

Tim

The following one-liner reveals duplicate bin names for both TDE and KDE4 environments:

for f in `/bin/ls -1 /usr/bin`; do if [ -e /opt/trinity/bin/$f ]; then echo $f; fi; done

Somebody with complete full installs of Trinity and KDE4 would be able to provide a full list of duplicates.

A full list might be unnecessary. A possible trick to reduce $PATH issues would be to create /usr/bin sym links to anything populated in /opt/trinity/bin. The file names in /usr/bin would use the tde- prefix. The LibreOffice folks do something similar.

>A possible trick to reduce $PATH issues would be to create /usr/bin sym
>links to anything populated in /opt/trinity/bin. The file names in /usr/bin
>would use the tde- prefix.
I still think this is the best approach. GNOME, Mate, and Cinnamon use respective prefixes in their /usr/bin app names. Using a prefix rather than a suffix would keep TDE consistent with the other desktops. Using tde- rather than trinity- would save some typing, but most people use *.desktop files and menus so mostly would not be bothered by the prefixes. I almost never need the prefixes when using the other desktops.

Populating /usr/bin with sym links to /opt/trinity/bin would be easiest to avoid $PATH issues. Each TDE module that creates a bin file would need a sym link. Perhaps this could be part of the common modules.

While too late for R14.0.0, hopefully this bug report is on the short list for R14.0.1.

I tested sym links in /usr/bin and ran KDE4. I tested running apps from within KDE4 konsole and had no problems running TDE apps. I had to type the 'tde-' prefix for everything in this proof-of-concept test, but if respective *.desktop files contained the same information, users would be able to run individual TDE apps in non TDE desktops and users would not need to tinker with $PATH.

$PATH should remain preset in starttde. Just change all respective *.desktop files to use tde-{appname} and create sym links when building packages.

In a test with Fedora 21 and R14, I ran 'kfmclient openProfile filemanagement' in a MATE desktop. R14 is installed to /opt/trinity. While konqueror opened and ran without errors, the environment is insufficient and konq does not use the user's profilerc file. Thus all file associations set in an actual full TDE session are ignored. The loss of file associations impedes konqueror's usefulness in other desktops.

Testing other apps, such as konsole, do not seem as significantly affected.

At this point I do not know how to resolve the file association problem. I believe the root problem is profilerc not being accessed.