Why KDE4 is called KDE?

[Draciron Smith]

On Wed, Dec 9, 2009 at 6:36 AM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
> On Wednesday, 2009-12-09, Draciron Smith wrote:
>
>> Actually it's the love of C++ for application level programming that
>> is really limiting the growth of Linux.
>
> Actually outside of KDE there is very little love for C++ on Linux, a lot of
> developers prefer C, especially when it comes to low level stuff.
> (With a few notable exceptions like Inkscape, etc)
> Probably a left over from the days where C++ wasn't really that easy to write
> in a portable manner.

Most of the tarballs I install are C++ or C. I rarely look closely
unless something goes wrong with the compile. True a disproportionate
number of those are KDE apps as I strongly prefer KDE apps over Gnome
apps. Though there are exceptions beyond the obvious like GIMP. There
is no KDE app that comes close to the GIMP.

Shrug I'm more comfortable in C than C++ just because there are fewer
black boxes. Other than that the two languages are essentially the
same and often intermingled and sometimes even with some Asm code. Asm
aint a bad language for a short program. Wrote many DOS Asm programs
but it got tedious fast if you had to write anything of any
complexity.

> I'd say it is actually a lot less common than e.g. on Windows. Basically every
> application by one of the big software vendors, including Microsoft, is
> written in C++.

I'll disagree there. The Linux world missed a HUGE opportunity as the
majority of apps out there are written in VB & the VB# languages. Yes
system level stuff is C++ well sorta. VIsual C++ is almost C++.  At
one point it was almost a decent language to write in. The early IDEs
for VC were really nice but M$ of course changed just to change.

The thing is VB code is far more portable to Gambas than it is too
.NET.  Millions of businesses and third party apps were left in the
lurch in a big way with the .NET migration and were desperate for a
way to keep their codebase. Much of this was middleware servers and
end user level application programming. For example all of the major
middle tier accounting packages for windoze were written in VB or
Delphi.  In the VAR world Delphi reigned supreme.  In terms of
shareware a huge percentage of it was written in VB or Delphi.  So
it'd made perfect sense to port to Gambas. More reliable servers, more
powerful and secure servers and they got to keep their code base. Not
just keep it, they didn't have to yet again forget everything they
learned and relearn how to program again.  Delphi had a Linux version
and Gambas was very close to VB syntax.

> However I think you have a point regarding Mac OSX. It seems to be a Objective
> C stronghold.

> When I started to work on Linux, I had done mostly Java programming on Windows
> (and Pascal and Basic on DOS before that).
> Interestingly Linux is the only platform I've worked on so far that seemed to
> have compilers and interpreters for all languages, additionally to already
> quite powerful programable shell systems (when compared to DOS/Windows Batch
> system).

True Linux is a programmers paradise. There is a compiler for just
about every language known to man, usually some very good ones.  The
IDEs have been slow to arrive but some of the Linux IDEs now rival the
commercial versions.

> I guess the difference leading to your point of view is the focus on certain
> languages.
> While Basic and Pascal (Delphi) are the strong ones on Windows, it is be
> Python/Ruby/Perl on Unix/Linux. If you are looking for things written in Basic
> or Pascal on Linux you might come to the wrong conclusion that only C/C++ is
> being used. Much like if you would look for things written in Python or Perl
> on Windows you'd come to a similar conclusion.

Python and Perl are very popular on Linux and gaining popularity even
among Windoze users. They are two examples I used. Gambas is another
though I think Borland  discontinued Kylix and I haven't seen anything
Delphi like to replace it on Linux. Gambas is new and gaining strength
and so is the .NET clone, forget the name off hand. WXBasic also shows
strong promise. Once the IDEs in these languages catch up then the
world opens up to mid level programmers and a whole slew of must have
apps will sprout in Linux.

The key though is exposing functionality in KDE, Gnome, GIMP, etc too
these languages. Right now it's hodgepodge. The language itself works
out a way. Perl has developed a rich set of libs to expose
functionality of common libs and apps typically seen on Linux distros
but it's taken years to build all these libs and they often lead to an
intricate dependency hell that inspired CPAN.  Python is just now
starting to get access to a great deal of essential functionality. In
the not so distant past a Python programmer often had to reinvent the
wheel any time they wrote anything elaborate in Python.

Linux really needs a new way to securely expose functionality to
different languages. A common set of APIs thus avoiding the potential
issues with security that arise from a 100 different apps doing the
same thing but differently for the exact same purpose but to expose
that same functionality to 100 different languages. There is excellent
support for C++ in this and that has led too so many useful and small
apps leveraging the work of other projects to provide a feature rich
environment but one that isn't bloated. Problem is it's all in C++ or
C.  For example look at how many apps leverage apps like Lame.

> Exactly. Which is why development tools/frameworks such as Gambas exist.
> There is also RealBasic which can be used to create applications running on
> Windows and Mac OSX as well.
>
> However, Basic frameworks seem to have more followers from the group of people
> already using Basic. Nowadays beginners seem to prefer Python.

Until recently Basic was not well supported on Linux. You had GWbasic
clones but lets face it GWBasic has been obsolete for 20 years.  Today
your seeing a large upswing in people in all the supported languages.
That is really supported. Just having a compiler doesn't mean support.
You need first class IDEs, you need fucntionality such as connectivity
too major databases, you need the ability to leverage existing apps
rather than having to write everything from scratch. Your starting to
see that with many languages now. The better the support for these the
more apps will come into existence.  For example right now I'm working
on a writer's editor in Gambas, which happens to be my favorite of the
app level languages. I've worked in Python, Rexx, Perl but for me
after years of writing VB code I feel more comfortable in a VB type
language/environment. I honestly don't care about Windoze portability
but would like to have portability to other Nix varients. That is just
a like not a need. So Gambas fits the bill for me. There are several
other good languages that will suit other people.  The point is word
processors are "Office" suites. They are great for writing a memo, a
legal document but they are rather worthless for writing a novel. They
beat using VI or something like that of course. However they lack most
of the necessary features for writing large scale efforts, as such
most authors either do like Piers Anthony did and hire somebody to
write custom software or they cover their walls with notes, keep large
paper binders full of info and printouts and kill massive numbers of
trees in their efforts.

I would have loved to have made it a KDE app but I honestly despise
working in C++ for anything but a short app. I'd love to take Kwrite
and use it for the most basic editing features and then add from
there. It'd be perfect for text editing and save me a great deal of
coding in not having to re-invent the wheel.

>> >> In practice, that singular entity rarely dismisses a modification
>> >> entirely, but does exert monopoly control.
>>
>
> I've yet to see any developer even considering a fork. So far such suggestions
> seem to come from bloggers and journalists with insufficient insight into the
> task at hand.
> Some of them even suggested stuff like forking KDE 3 era code and porting it
> to Qt4, ignoring the man-years of work that it took the code base maintainers
> to do that.

I have not looked at what it would take. Haven't even opened KDE
source code in years. Yes it may take years to do but the level of
dissatisfaction with KDE 4 is so great that people are not going to
bite the bullet and put up with the loss of functionality.

You also forget KDE 4 has done most of the work of porting for QT
already. A huge chunk of the functionality is already ported, quite
possibly all the essential stuff is already done in KDE 4, from there
it might just be a matter of returning functionality and removing
damage like the plasmoids. Should be trivial to revive support for
multiple desktop background images for example.  Adding applications
too the panel should not be a huge deal. The QT lib support is already
there, if the code in 3.5 was good code that should be fairly well
insulated or easy to modify based on other KDE 4 functionality.  Again
I preface this with not having looked at the code yet.  Something I'd
rather not do as time constraints and working in C++ are two factors.
It does beat having to put up with Gnome, XFCE or KDE 4 though. The
time I lose from lost functionality in KDE 4 will quickly equal the
time necessary to make KDE 4 usable. As it stands I gain nothing using
KDE 4. I could use Gnome and be just as productive. One of the big
draws for me with KDE 3.x or earlier was it saved me heaps of time. It
helped me be much more productive. I spent less time doing things
because I could customize it to fit MY needs. KDE 4 has lost almost
all of that customization. It is a one size fits all solution.


> So one could for at a stage where all the porting has happend already,
> something like 4.0 release stage.
> But why would anyone throw away all the things done between then and now?

Because it tears at everything that made KDE dear to a large number of
people. KDE 4 is NOT KDE except in name. It has betrayed the
principles and ideas that made KDE so successful.

> So if one forks the state of trunk now, why would any exisiting developers
> work on whatever they are working right now just in a different repository?
> I think we can be pretty sure they are not likely to work on a different area
> of the code base because they could to that right now as well.

I think any developers that defect will mostly be %100 defectors. As
far as I know I've not met or talked too any KDE developers. I suspect
some have left the project in protest of what's happened, which might
explain why Kedit is suddenly no longer supported.  There are others
that I'm still trying to find besides kedit which seem to have
vanished in KDE 4, but it might be they are just religated rather than
unsupported. Hard to say yet.  Kedit though has been a mainstay of KDE
for many years. It is by far the best lightweight text editor around.
I made the mistake of editing grub.conf the other day in Kwrite and it
corrupted the file beyond use. Didn't take a hex editor to see what
the damage was but Grub puked every time I tried to boot. Re-wrote the
same exact syntax in VI and Grub was perfectly fine with it. It wasn't
a missing CR as I was fanatical about making sure the CRs were in the
right places. So there was some sort of garbage introduced by Kwrite.
One of many annoyances I have with Kwrite. I'm finally starting to
remember why I quit using that app many years ago in favor of Kedit.
I can assume that something traumatic happened to cause the loss of
kedit.

> Actually an interesting fact about those fork suggestions is that they come
> from the context of people being unsatisfied with the Plasma desktop.
> Interestingly none of those fork suggestors seems to consider forking just
> KDesktop+Kicker.

That is actually a good suggestion. %95 of KDE is things people do not
see. It is probable that some of that needs to be mucked with too
support higher level functionality but as much as possible that should
be left alone if it works and allows the modifications necessary to
Kdesktop which is really the core of the ire being generated.  Mostly
it's a loss of functionality. I could put up with the goofy plasmoid
if I could add apps too the panels, work with the panels like I did in
KDE 3.x and had the same abilities I did in KDE 3.x.  KDE 4 on this
machine/distro combination is MUCH slower. How much is distro and how
much is KDE 4 I don't know.  Until I HAD too upgrade because my
install (Fedora 8)  end of lifed on this machine I was VERY happy with
the performance on this machine. I tried out an Ubuntu varient but
unfortunately it end of lifed shortly after I installed and is no
longer supported. I tried out an OpenSUSE distro on this machine again
using KDE 3.x and like the other distros performance was excellent.
Second I installed Fedora 12 with KDE 4 my machine slowed.  I'll be
installing OpenSuse and Ubuntu varients on another machine and see if
that makes a difference. Though I see no reason to replace the default
Gnome desktop with KDE like I'd planned to do with Ubuntu studio.  KDE
4 has no functionality above and beyond Gnomes and I think the current
Gnome is actually more customizable than KDE 4.  It's been a while
since I used Gnome for anything more than a temp desktop that allowed
me to get KDE installed.

So potentially a fork on Kdesktop is far more logical. Depends on how
difficult it'll be to add back all the lost customization and
functionality.  The main thing really boils down to people having
their desktop THEIR way.  If I want to write a script and run it from
the panel why shouldn't I?  Yet to do that in KDE 4 I'd have to first
write code to add that script to the KDE menu. Then I could drag and
drop. That is an insane amount of work to add a console app. I STILL
haven't been able to add FIrefox to the menu much less the panel. A
trivial task in KDE 3.x.  On my main desktops I see only little bits
and pieces of the actually desktop. The desktop folder is rather
useless to me. It is an accident waiting to happen and nothing more.
Those are some of MY gripes. Others miss different things but they
relate to the same concepts. KDE before version 4 emphasised ease of
customization, flexibility and facilitated such. KDE 4 says this is
how your going to use your desktop like it or not . Folks are
responding with a loud and clear NOT.

It's not going away either. Think about it. If folks wanted a hard to
customize desktop manager why change off the default Gnome which comes
with most major distros. Fedora, Ubuntu, etc all default to Gnome as
the default desktop manager. Most Debian based distros same thing. Yet
KDE's popularity has been such it's forced Kbunutu and a KDE live spin
and such. The reason is the appeal of KDE has been that strong, an
appeal based not on colors or functionless eye candy like the
plasmoid. Come on you could lock your panel going back to what KDE 2?
IT was a right click away.  Aside from locking your desktop what
function does the plasmoid server other than eye candy? It's no faster
to log out using the plasmoid than the menu. If your in such a hurry
you can just drop the logout applet onto the panel.  Me I log out and
reboot a few times a year once I have everything the way I like it.
Only for security updates to the kernel usually will I reboot unless
I'm on a laptop.

So what does the plasmoid gain for most people?  Not much.  That is
the ONLY addition I'm aware of. I'm sure there are under the covers
improvements. Not sure what though. I had identical funcitonality with
Kenetwork manager in KDE 3.5. I do like that SELinux troubleshooter
has finally arrived for KDE. Gnome has had it for a long time and it
was annoying to have to use switchdesk to go look at SELinux alerts in
Gnome. I'd rather put up with that than lose all the stuff I lost in
KDE 4.  I've dared a couple people to name improvements in KDE 4 and
none have taken that dare.  The new menu is useless if you have
hundreds of apps it'll take you a week to get to the ones at the end.
The old menu made it easy to get too an app. At worst you were a few
clicks away from anything installed in your menus. Just to change your
resolution in KDE 4 you need 5 clicks.  If you have a mere 100 apps in
a sub menu it might take you a dozen clicks or more to find and launch
an app and if your not sure WHICH menu it was in your just better off
running it from the console cause it'll take you days to find it.
The menu system that KDE 4 defaults too works OK with Windoze cause
you can't possibly install that many apps without corrupting the
registry. This is Linux though. People like me who heavily use their
computer can have thousands of apps installed.  That means hundreds in
each sub menu. At the 10 or 12 per screen display that means 10-12
clicks on the more apps down at the bottom to finally get too some of
them.



>
> Cheers,
> Kevin
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
>
> ___________________________________________________
> This message is from the kde mailing list.
> Account management:  https://mail.kde.org/mailman/listinfo/kde.
> Archives: http://lists.kde.org/.
> More info: http://www.kde.org/faq.html.
>
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.