LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 12-26-2013, 02:46 PM   #1
Hysteresis
LQ Newbie
 
Registered: Jun 2008
Location: Dallas, TX
Distribution: Variety of 'buntu distros on 5 systems.
Posts: 4

Rep: Reputation: 0
Apps from DE's "foreign" to your chosen/preferred DE.


I'm posting this on the newbie board even though I've consistantly been using Linux since 2007, and intermittantly since RedHat 5.1. This seems to be tied to such a fundamental set of choices it seemed more appropriate here. Sorry for the TL;DR presentation but I wanted to cover as much as I could in one post. Note that I'm not looking for a fix for the systems with issues, I'm looking to correct my philosophical approach to distro installations and subsequent app installations.

I've encountered (or maybe I should say finally identified) an issue that has been nagging me increasingly for the last few years on my various Linux boxen: the issue of apps foreign to the native desktop environment causing strange behavior in the native DE. Strangely, my earliest install of a Linux distro I used regularly, Kubuntu 7.04, 'Feisty Fawn', never seemed to have a significant problem with foreign (typically Gnome) apps. I could install anything from the repository and it would automagically run just fine, except maybe with less pretty windows for the foreign app. I ran with that install until even the 'old' repositories finally were closed and I could not get various programs I was interested in installing.

Since then, I've been encountering various symptoms and issues on newer distros and different installations I've tried since the Feisty Fawn install that I finally have identified as probably being due to the Qt vs. GTK+ issue. The 'automagic' aspect of the DE resolving KDE vs Gnome apps seems to be gone.

This initially became most obvious for me when I installed LXDE on an old P3 laptop. After installing foreign apps (both GTK+ & Qt based), the LXDE start menu was munged. Only programs installed with the last GTK+ based app were present. No other start menu entries for other programs were present. After delving deeply into the philosophy and architecture of the desktop menu entries (http://www.freedesktop.org/wiki/Spec...op-entry-spec/ & http://www.freedesktop.org/wiki/Spec.../basedir-spec/ ) and verifying everythig appeared to be right in my system (all the '.menu' entries were present and correct) I finally accepted something else was going on.

Now if I were only running simple browser, office apps, MP3 & video players I could just stay with the appropriate choices offered by each DE "camp". Unfortunately I tend to use scientific, ham radio and other less common software where there are far fewer choices. That means I still have to co-mingle Qt & GTK+ apps on whatever DE install I'm using. The most obvious one is OpenModelica which uses Qt for plotting and PythonGTK for other stuff. (That's the install that appears to have munged the Start menu entries in LXDE.)

Then I just happened to rearrange my desktop icons on my main machine running Linux Mint 12 KDE and noticed something I'd overlooked previously: some of the icons weren't using the same 'styles' for presentation. I had been having a problem with the system where most of the desktop and many of the aspects of the desktop elements didn't seem to follow the 'theme' I had selected and would not change when I made changes via the KDE 'System Settings' panel. While I suspected it had somehow adopted some Gnome settings, I didn't pursue the issue since I was limited on time. Now the two different icon 'themes' seemed to verify that diagnosis even though this is a KDE system, somehow the underlying Gnome DE seems to be significantly influencing how the KDE destop operates while ignoring the KDE theme mechanism.

Now my question is: how to prevent this from occurring in the future? Since I need applications that come from both environments, I will always need to keep the apps from the foreign DE from hijacking the native DE. Is there a core group of packages I should be installing to prevent this from happening? Since some of my old H/W really doesn't run satisfactorily under the current KDE & Gnome DEs, I'll probably be running LXDE (or a similar low demand DE). In that case, would performing an initial instal of 'gnome-core' and 'kde-baseapps' bring in enough packages to satisfy most Qt & GTK+ requirements of other apps without hijacking the preferred DE installation? Should I install 'gtk-qt-engine' or some similar mechinism to resolve gtk/qt issues? (Again, I'm only looking for philosophical approach, not a nuts & bolts answer.) Should I be setting up a VM to run these foreign apps in my preferred DE? That's less attactive to me but certainly tolerable compared to what I've been encountering.

I'm curious how others have resolved this issue of running foreign DE apps in their preferred DE. (Note that in all cases, these are apps coming from some Debian originated Distro repositories appropriate from the installed DE so they are not 'alien' apps from a Red Hat repository. That would be a significantly different issue.)
 
Old 01-23-2014, 06:10 PM   #2
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Stretch (Fluxbox WM)
Posts: 1,389
Blog Entries: 52

Rep: Reputation: 355Reputation: 355Reputation: 355Reputation: 355
There are a few issues that you raise here. Simply installing some gnome or kde core libraries isn't going to solve this.

From my point of view, if installing a particular package breaks your menu completely, it is a bug, and can be reported to the maintainer of that package (distro maintainer, not upstream). Plenty of people mix GTK and Qt applications without this happening.

Then there are the cosmetic issues, including the inconsistent theming. As a user, these don't bother me as much; any package I spend enough time using I get used to. I have no easy answer to this; if it bothers you enough, you could have different logins which run different desktop managers (using a VM seems like overkill). But in the long term, these cosmetic issues are a problem. First impressions of an operating system are important for its takeup, and inconsistencies in presentation do affect people's perception (even though this has nothing to do with the underlying quality of the individual packages). You may find some help here.

I personally have a very minimal desktop environment (really just a window manager), so I don't encounter all of these issues (there is no 'theme' as such). There are some applications which not install a compatible menu entry; I get around this by creating my own menu entries in these cases, but it is a little annoying.
 
1 members found this post helpful.
Old 02-06-2014, 08:06 AM   #3
Hysteresis
LQ Newbie
 
Registered: Jun 2008
Location: Dallas, TX
Distribution: Variety of 'buntu distros on 5 systems.
Posts: 4

Original Poster
Rep: Reputation: 0
The cosmetics really aren't that important to me. (Heresy in this era of eye candy desktops.) It's the overall functionality and speed of the various apps that I value. That's why I hadn't addressed this issue until things got way off track and broke the functionality of the DE's. That's when I began to look at the situation from a Big Picture perspective and not at the low level of trying to resolve lots of little annoyances.

I wondered for quite awhile if these issues were possibly bugs or just a misunderstanding on my part. If they are bugs, that will require a lot of effort just trying to get the developers to see the issues as bugs if hundreds (thousands?) of others aren't experiencing the same issues. If it's due to a misunderstanding on my part - well, that's why I posted this thread. It's my attempt at a reality check. I'm wanting to make sure I'm not misunderstanding how the apps from foreign DE's should play together. It's another reason I intentionally omitted any mention of the actual distros where this has occurred. Until I rule out my own mis-behavior I don't want to point any fingers. It's why I posted this as a philosophical discussion and not a nuts-and-bolts debugging question. Actually I'm usually able to resolve those issues with sufficient applications of time and Google-fu. This one I struck out on after extensive Googling. Everything I read indicated Things Should Just Work (but maybe not look as pretty).

If this problem persists with newer distros I try (or specific apps I identify as the culprit), I may use grub to setup booting into a different DE just for that app as a short term fix for myself.
 
Old 02-06-2014, 09:07 AM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,704

Rep: Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270
Unfortunately, the various desktops are gradually claiming the same libraries for displays (qt for instance). This causes more and more of the utilities for a specific desktop to start failing when used with other desktop environments - the assumptions made by the utility about the library are no longer quite "valid", and configurations for one desktop will conflict with assumptions for other desktops.

Usually caused by using the same configuration file for both desktops...

It used to be easy - just specify the environment to the X server, applications would then retrieve those appropriate to it. It allowed utilities running from any remote system to get a common configuration, maintained in one location. Now the "environment" is being specified by the desktop, and not necessarily in a compatible way for all utilities - with local configuration files for each system, incompatible IPC methods, and making it impossible to have consistency.

And that requires every utility to workaround problems caused by others, and a lot of "not my problem" results, as in "works on this system, but not that one"
 
1 members found this post helpful.
Old 02-07-2014, 10:36 AM   #5
Hysteresis
LQ Newbie
 
Registered: Jun 2008
Location: Dallas, TX
Distribution: Variety of 'buntu distros on 5 systems.
Posts: 4

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by jpollard View Post
Unfortunately, the various desktops are gradually claiming the same libraries for displays (qt for instance). This causes more and more of the utilities for a specific desktop to start failing when used with other desktop environments - the assumptions made by the utility about the library are no longer quite "valid", and configurations for one desktop will conflict with assumptions for other desktops.
Are you saying they are using the same library names or the same actual libraries? If the same actual libraries, I'd think that would be a Good Thing. (Unless they were different releases. Then that would be a massive problem.) Supposedly having the same libraries with the same version code should give the same results. The only difference then would be what the DE was doing with that library, but that should be under proper control of the DE.

I can see if an app makes a DE call and the variable name is the same in different DEs but perform different actions. That would be Really Bad. Is that what you're saying? That may become unmanageable in the type of environment I need. That would certainly point me towards needing a multi OS system at boot.

I just haven't kept track of what's been going on at the various distros in the last three or four years. Once I got my original foundation information on Linux I've focused on the applications and real work, not the underpinnings. It sounds like the underpinnings have changed at the detriment of the flexibility of the userbase. I just need to learn the new ground rules. I suspect this is why I've seen so many post about the various distros they have on their systems via multiboot. I thought it was just that they like trying lots of distros. Now I'm beginning to suspect that is their fix for the kinds of issues I'm having.

(The first real dissonant chord in Linux-land that affected me was the PAE flag problem. That was a real boneheaded mode by the kernel crew. To just base the PAE flag decision solely on the CPU and not the supporting chipsets was a case of cranialintraanalosis. The most popular chipset of that era was the 440BX, and it's not PAE capable. They immediately created millions of tons of needless e-waste as a result of their decision. But I digress.)

I'm going to leave the thread open for a couple of days to see if you have anything else to add to help enlighten me. I suspect you've already given me the direction to the real answer - multiboot and don't look back. I don't like the answer, but it's an answer.
 
Old 02-07-2014, 10:57 AM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,704

Rep: Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270
Quote:
Originally Posted by Hysteresis View Post
Are you saying they are using the same library names or the same actual libraries? If the same actual libraries, I'd think that would be a Good Thing. (Unless they were different releases. Then that would be a massive problem.) Supposedly having the same libraries with the same version code should give the same results. The only difference then would be what the DE was doing with that library, but that should be under proper control of the DE.
They are using the same libraries, then modifying them for their own use. This has caused issues between Cinnamon and Gnome, and it spreads to others. Cinnamon now uses its own libraries that are separate from the ones Gnome uses, though both are based on qt. Now it is possible that the only differences is in the internal definitions for where configurations are stored - but putting that in the library is IMO stupid.

Quote:
I can see if an app makes a DE call and the variable name is the same in different DEs but perform different actions. That would be Really Bad. Is that what you're saying? That may become unmanageable in the type of environment I need. That would certainly point me towards needing a multi OS system at boot.
That is what it looks like.
Quote:

I just haven't kept track of what's been going on at the various distros in the last three or four years. Once I got my original foundation information on Linux I've focused on the applications and real work, not the underpinnings. It sounds like the underpinnings have changed at the detriment of the flexibility of the userbase. I just need to learn the new ground rules. I suspect this is why I've seen so many post about the various distros they have on their systems via multiboot. I thought it was just that they like trying lots of distros. Now I'm beginning to suspect that is their fix for the kinds of issues I'm having.
It depends on "when". I didn't see the problem before Gnome 3.5. When Fedora 19 came out (I think that was the one, might have been 18) the Cinnamon project had to duplicate the libraries/rewrite because of the slight variations Gnome added to the libraries.

It appeared to be more than just a minor update to a library should have. Minor updates SHOULD be compatible - here, they weren't.
Quote:
(The first real dissonant chord in Linux-land that affected me was the PAE flag problem. That was a real boneheaded mode by the kernel crew. To just base the PAE flag decision solely on the CPU and not the supporting chipsets was a case of cranialintraanalosis. The most popular chipset of that era was the 440BX, and it's not PAE capable. They immediately created millions of tons of needless e-waste as a result of their decision. But I digress.)
I can't fault the kernel developers on that - vendors made the older chipset work with the newer CPUs, even though the PAE flag should have worked. It was a small change (viewed from outside the CPU).
Quote:
I'm going to leave the thread open for a couple of days to see if you have anything else to add to help enlighten me. I suspect you've already given me the direction to the real answer - multiboot and don't look back. I don't like the answer, but it's an answer.
I'm hoping things work out eventually. Unfortunately, all of the libraries are moving to custom, non-shared (and non shareable) configurations which will cause running utilities remotely to "not do the right thing" just because they don't have copies of all the configurations done on the client system. That was the purpose of x resource support, to provide the same resource definitions to all utilities no matter where they were running.
 
1 members found this post helpful.
Old 02-08-2014, 12:02 PM   #7
Hysteresis
LQ Newbie
 
Registered: Jun 2008
Location: Dallas, TX
Distribution: Variety of 'buntu distros on 5 systems.
Posts: 4

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by jpollard View Post
They are using the same libraries, then modifying them for their own use. This has caused issues between Cinnamon and Gnome, and it spreads to others. Cinnamon now uses its own libraries that are separate from the ones Gnome uses, though both are based on qt. Now it is possible that the only differences is in the internal definitions for where configurations are stored - but putting that in the library is IMO stupid.
You are too kind. It's the height of stupidity. It violates every aspect of accepted configuration management for production grade software. I suspect it reflects the migration of the professional greybeards away from the frontline coding and newer "aggressive" hobby coders (or recent uni grads) entering the scene over the last decade. They're still in the "ooh-shiny, I want it now" mode and haven't learned the value of "hmm, reliable" after being severely burned a few times and held accountable for fixing their highly visible FUBAR. Thanks for the background and deeper insight. That certainly clarifies the need to keep apps running under the DE they were originally developed for and not consider them DE agnostic anymore. (And I had such hopes for the Linux Standard Base eventually bringing everything together.)

Quote:
Originally Posted by jpollard View Post
I can't fault the kernel developers on that - vendors made the older chipset work with the newer CPUs, even though the PAE flag should have worked. It was a small change (viewed from outside the CPU).
I found the archive with the message thread where the kernal developers discussed the PAE flag issue. They only considered the CPU as if that was the only thing that affected the flag. Not being a coder myself, I'm not familiar with the checks and machinations needed to deal with that issue. I just know it immediately obsoleted several of my decent machines that can't boot any recent PAE enabled distro. I'm hoping at least Lubuntu will incorporate the new(ish) 'fake-pae' package during boot to renew the usability of those legacy machines. (I still want to 'thwak' some of the kernel devs on the back of their head over the PAE issue. They should have considered not just the primary issue, the CPU, but the secondary issue, the chipsets, as well. Ideally they should have also considered the tertiary issue, support in the BIOS, but that would have been almost impossible for a resource limited group like the kernal devs. Plus, the BIOS' PAE ability would probably have been reflected in the chipset being used. Relatively speaking, any machine with max memory of 512M is probably a non-PAE machine, even if a P4. That's a massive number of otherwise good machines that can't currently benefit from most Linux distros. I'm still keeping my fingers crossed for Lubuntu or other LXDE variants.)


Quote:
Originally Posted by jpollard View Post
I'm hoping things work out eventually. Unfortunately, all of the libraries are moving to custom, non-shared (and non shareable) configurations which will cause running utilities remotely to "not do the right thing" just because they don't have copies of all the configurations done on the client system. That was the purpose of x resource support, to provide the same resource definitions to all utilities no matter where they were running.
This simply reinforces the need for multiboot if one is running apps from a foreign DE (and an absolute must if you think you neeed to run 'alien' to install an RPM package in a Debian based system.)

Again, thanks for the info. It clarified and solidified my suspicions. I'm going to mark this question as 'answered'.

Last edited by Hysteresis; 02-08-2014 at 12:09 PM. Reason: correction
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] GTK Apps ignoring chosen GTK theme TheStarLion Ubuntu 4 11-28-2009 06:50 AM
how can I set preferred apps other than web browser and email client in Ubuntu 7.04? atmartin50 Linux - Newbie 2 05-22-2007 02:18 AM
preferred apps in FC3 snafu Fedora 3 04-16-2005 01:35 PM
FC3 preferred apps dubya Fedora 3 03-05-2005 12:51 PM
Preferred way of installing apps? Vote / Suggest aesahaettr Linux - General 6 04-30-2004 09:34 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 08:05 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration