Subject: Re: [linux-audio-dev] ANNOUNCE: Rosegarden-4 v0.1.5 released
From: Likai Liu (news_AT_likai.net)
Date: Mon May 06 2002 - 05:29:19 EEST
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
This archive was generated by hypermail 2b28 : Mon May 06 2002 - 05:22:21 EEST