Do you want a bug open on this one, or just push it? I think it is small enough just to push it. Get our fearless leader to comment, but unless someone wants a bug opened, I'd just push it if all give the nod.
I will push changes for the few *.desktop files discussed.
As I mentioned, the core problem is not OnlyShowIn=TDE but the XDG_* environment variables. In the broader scheme, we have no remedy for getting other environments to source /opt/trinity in the XDG_* environment variables.
In distros that use /etc/profile.d, the solution is to ensure a script is installed (could be nothing more than the normal trinity.sh script). For the distros that don't use /etc/profile.d, such as Debian, I don't know how to ensure XDG_* variables are modified to recognize /opt/trinity.
As I mentioned, when KDE4 is concurrently installed with Trinity, the result will be a menu mess one way or another, unless we provide distro maintainers a more organized menu structure to handle the KDE4/Trinity overload.
Some might ask, why would users install Trinity and use a different environment? Many users prefer window managers rather than full desktops, but prefer a selection of apps from the full desktop environments. Many systems are multi-user, and the various users select what to run. In those instances, all options must be installed.
There is a growing restlessness in the KDE4 community for PIM apps that do not rely on the akonadi/nepomuk foundation. Trinity PIM apps could fill that role, but without modifying the XDG_* environment variables, the apps won't be found in non-Trinity desktops.
Darrell
On 02/12/2014 12:08 PM, Darrell Anderson wrote:
I will push changes for the few *.desktop files discussed.
As I mentioned, the core problem is not OnlyShowIn=TDE but the XDG_* environment variables. In the broader scheme, we have no remedy for getting other environments to source /opt/trinity in the XDG_* environment variables.
In distros that use /etc/profile.d, the solution is to ensure a script is installed (could be nothing more than the normal trinity.sh script). For the distros that don't use /etc/profile.d, such as Debian, I don't know how to ensure XDG_* variables are modified to recognize /opt/trinity.
That brings us to the point of -- "What is a proper XDG_* environment for trinity?" Right now in tqtinterface, we have complete control over the XDG environment with trinity.sh. I currently have:
export TDEDIR=/opt/trinity export TDEDIRS=$TDEDIR export PATH=$PATH:$TDEDIR/bin export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$TDEDIR/lib/pkgconfig if [ ! -z $XDG_DATA_DIRS ]; then export XDG_DATA_DIRS=$XDG_DATA_DIRS:$TDEDIR/share else export XDG_DATA_DIRS=$TDEDIR/share fi if [ ! -z $XDG_CONFIG_DIRS ]; then export XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:$TDEDIR/etc/xdg else export XDG_CONFIG_DIRS=$TDEDIR/etc/xdg fi
What additional can we do/(do better) with the environment setup?
As I mentioned, when KDE4 is concurrently installed with Trinity, the result will be a menu mess one way or another, unless we provide distro maintainers a more organized menu structure to handle the KDE4/Trinity overload.
Some might ask, why would users install Trinity and use a different environment? Many users prefer window managers rather than full desktops, but prefer a selection of apps from the full desktop environments. Many systems are multi-user, and the various users select what to run. In those instances, all options must be installed.
There is a growing restlessness in the KDE4 community for PIM apps that do not rely on the akonadi/nepomuk foundation. Trinity PIM apps could fill that role, but without modifying the XDG_* environment variables, the apps won't be found in non-Trinity desktops.
Darrell
+1 When I was shopping desktops, it was not uncommon to have kde3, kde4, wm2 fvmwm2, e-16, e-17, gnome, fluxbox, twm, blackbox, openbox, etc. all installed simultaneously. The only real havoc was caused by kde3/kde4/gnome. That's why the X11 project put out an entire menuing standard to handle what is isn't visible in each desktop. I've picked through the standard, but never compared between what we have and what is says. Further, in doing so, I don't ever recall seeing a clean way of preventing the kde3/kde4/gnome menu mess. It is almost as if there is a need for a global 'menuedit' to manage /etc/xdg/menu on a global and per/user basis to include/exclude apps in menus when multiple desktop environments are installed.
-
Darrell Anderson -
David C. Rankin