I have a few more things to say again. You don't need to have the KDE desktop environment running in order to use KDE applications. All KDE applications (say, those that use DCOP) know how to start a basic set of core, life-supporting KDE processes, and these kdeinit processes do clean up afterwards. The kde core processes are included in kdelibs rpm, which is a separate package than kdebase. I oftentimes start some KDE applications from gnome, but it will start regardless of your environment anyways. In this case, KDE will use whatever window manager you are already running instead of trying to start its own. In fact, KDE only launches a window manager if you start the complete KDE environment by running the startkde script.
Rick Burnett wrote: >There is *always* going to be that uphill battle, whether you are >using a standard desktop library or GUI libraries. Desktop's change >too, and what is to say KDE doesn't in the future redesign thing again >as in KDE1 to KDE2? > >I totally disagree that the *easiest* path is the best path to take >just to get something realized in real code. > It is rather unfortunate how these non-standard open source API keep changing at the author's will, but I think the easiest way is still the best way to go. A library is easier to use because 1) it helps the application that use it to define a good, clean infrastructure so actual functionality can be done, and 2) its API doesn't change too much such that an application developer needs to spend too much time keeping the application up to date with the library. The application developer has all the right to decide what is easier. At the end, more developers will tend to choose the commonly easier to use libraries in general, and when the end user use the application, they'll choose the library or integrated desktop environment that is more commonly supported by the applications. There is nothing wrong with this open-computing cycle that involves a bit competition. It is interesting to notice that this competition doesn't weed out losers, though. No matter how unpopular your software is, there is always someone who use it. >Because KDE is not standard. You are making an assumption on what >people should use as a desktop and I know enough people NOT using KDE >for me to believe that it will never be a standard under Linux. There >will be no standard WM. > Again, Rosegarden does not determine which windows manager you use. You just need to have a (rather huge ~ 30MB) kdelibs installed. If you just don't like the user interface metaphors in KDE that is also in Rosegarden, you're free to choose another music sequencer software. The software doesn't choose its users. It's the users like you and me that choose the software. >Linux is not an operating system for simple users. It requires you to >actually *think* about what you need to do. Every assumption you make >takes away the freedoms that linux gives you. > <digress> I'd like to see more people working out a simple solution of linux for simple users. I think KDE 3.0 as an environment is approaching this goal. GNOME 1.4 is lacking a bit behind, but I sincerely look forward to GNOME 2.0 to come out of the beta stage. I want to emphasize that most users don't care about system configurations. They only care if they can use the computer for e-mail, web, music (that's us!), and occasionally some enjoyment. It might even be better off that a desktop environment does not try to cover every single details of system configuration, so people who are not competent enough don't end up screwing up their system. Think about why some people who use Windows have to reformat their hard disk every 3 months. From the view point of a developer, KDE is both slightly advantageous and disadvantageous. C++ is a great language for modularity and productivity of development cycle, and I do think Qt has well designed (programming) interface. But C++ in its binary form is also extremely compiler sensitive. Redhat makes this matter worse by using their own customized, unofficial 2.96 version of gcc, which produces binary incompatible code with either official 2.95 series and 3.0 series. This act of Redhat is hitting KDE hard in the dark. While GNOME's gtk uses plain C, which does not have binary incompatibility problems, gtk's use of macro wrappers as an attempt to bring about some object oriented features doesn't adequately define the infrastructure of programs that use gtk, which makes it very easy to use gtk "the wrong way" and therefore hurt programming efficiency. I'm not familiar with C++ gtk wrappers like gtk-- at all, but I welcome comments and inputs. </digress> >RB> Is it better having some software that works on a subsection of computers >RB> than none that works on lots? > >No. Not in my opinion. To me it is better to have software that >works for the majority of users than a minority. If I felt as you do, >I would just use windows. > Isn't windows the other way around? I mean, Windows has the software used by the majority, but its functionality actually works for many simple end users. So I guess you would be better off using Windows? ;-) <digress> To my utmost curiousity, the Windows API hasn't had significant changes since 1994 when the Win32 API was first implemented in Windows NT 3.1. That was 8 years ago. You can still run the legacy programs that use Win32 API on modern systems. To go back to your point that states "there is *always* going to be that uphill battle," maybe when library developers design their API, they should consider more of backward compatibility. As far as I concern, if I have qt3 installed (for kde3), I can only compile/run qt2 applications if I have qt2 also installed. Same goes for gtk2/glib2. Of course I'm not encouraging anybody to develop using xlib, which is really *the* standard across most unix systems. </digress> This thread has been a long tedious discussion that is pretty out of topic on this mailing list. I wish what I wrote here would satisfy those who thought about debating on. If not, we can always discuss this offline. liulk
