Why KDE4 is called KDE?

[Kevin Krammer]

On Wednesday, 2009-12-09, Draciron Smith wrote:
> On Wed, Dec 9, 2009 at 6:36 AM, Kevin Krammer <kevin.krammer at gmx.at> wrote:

> > 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.

I know that quite some software is written in VB which is why I specifically 
wrote "vendors".
Products like Micrsoft Office, Adobe Photoshop, etc. are basically all written 
in C++.

VB is huge on in-house or custom built solutions.

Unfortunately there is nothing "the Linux world" can do about VB not being 
available for Linux, the respective vendor does not offer that product and has 
even discontinued the traditional version for its own platform.

There are Basic based development frameworks such as Gambas or RealBasic.
The latter being a commercial product running also on Windows and Mac OSX and 
as far as I know claims to have some kind of VB importer/converter to make 
changing to it easier,

> 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.

Exactly.

> 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.

Interesting.
I knew that Delphi had a huge following but thought that VB was mostly be used 
for projects which are not sold (but for all scales)

> 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.

Well, since there is Gambas and I've heard it is quite a sophisticated 
framework, doesn't this fulfill the requirements for attracting basic based 
developers? In masses?

> > 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.

I think Borland gave up on the development tool business, i.e. sold this part 
of the company to some other firm.
If I remember correctly they've made a huge mistake with Kylix when they 
introduced a new component model instead of using the same one Delphi used.
They probably wanted to switch Delphi as well, but just resulted in Kylix 
being ignored by Delphi based developers.

However, I think the FreePascal people have a component model as well, not 
sure how it compares to Delphi though.

I wouldn't call Gambas inew", it has been available for years and seems to 
have loyal followers and all. But I haven't seen any common application built 
with it yet so my guess is that it is, quite like VB, mostly used for in-house 
and custom solutions.

> 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.

Both KDE and GNOME (as well as frameworks they build on like Qt or GTK+) have 
had bindings for a number of languages for years, Python being one of the best 
support ones.

I think the printer configuration tool for KDE is written using PyKDE, GNOME 
land seems to have a few more due to plain C not being that much of an 
alternative like C++/Qt is.

The tools are there, have been for years, but the prognosed huge influx of 
willing developers has yet to be detected.

> > 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.

Probably depends how you define recently,
Gambas has had late 1.x releases in 2007 so it is probably around for 3 or 4 
years. KBasic is definitely older, I remember being subscribed to is 
mailinglist in the early 2000 years (probably 2002).

> 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.

I mainly see people using Python more, haven't seen any Basic app yet and Ruby 
seems to be mostly used for server stuff (Ruby on Rails, etc).

> 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.

One doesn't have to use C++ to write an application using KDE technologies.
There are bindings for several languages, the two most active ones are 
probably Python and C#.

The editor component used by KWrite is also used by other apps (such as Kate 
or KDevelop) and I am pretty sure it is available in the bindings as well.
But that's probably better discussed on the bindings list.

> > 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.

Most complains I've seen about "loss of functionality" seems to be targetted 
at the workspace and there again mostly panel and desktop.
Yet there hasn't been anyone trying to implement these two comonents 
differently so I find it highly unlikely that there would be enough developers 
to actually maintain, even less develop, a full fork.

Which is why I usually suggest to try developing and maintaining a Qt4 port of 
KDesktop and Kicker first, because even that is going to be a lot of work.

It's not likey anything would depend on a specific implementation for those 
items, otherwise applications would run on other workspaces such as GNOME's.

> 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.

Another advantage of doing alternative workspace components is that one 
doesn't have to remove anything.

> 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.

From what I've heard and read one of the reasons a replacement for KDesktop 
and Kicker was introduced is that the old code was not good code anymore but 
full of hacks thrown in for all kinds of features over years of development.

But I haven't had a look at the code myself, could be exaggerated (though I 
doubt it).

> 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.

Desktop and panel can be separate applications, one could use any technology 
available that allows creating processes with a GUI.
E.g. (since that came up earlier) Gambas.

> > 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.

Quite overgeneralizing statement.
Most of KDE's products is exactly like they used to be, often developed a lot 
further, e.g. Okular surpassing KPDF by far.

> > 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.

I think the last developer who left in protest was Neil Stevens (or whatever 
he was called). Fun thing that :)

Kedit was actually maintained for a while after the porting but it seems it 
became unmaintained again a bit later.
Or maybe its development moved to a different source repository.

The main point is that as an application developer I would want to continue 
developing whatever application I am currently working on, not climb down into 
the trenches of library work or work on totally unrelated apps.
I could do that right now as well, or leave the base work to people I know do 
be capable of doing that.

Which is why, again, development of alternative workspace components is a lot 
more likely to achieve anything, even if it is just reaching enough stability 
to be of use to the ones developing them.

> > 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.

I'd say the other way around. Sure there are quite some lines of code in 
kdelibs, but some of the application modules have large numbers of 
applications, e.g. kdegames, kdeedu, or big ones, e.g. kdepim.

> 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.

My guess would be that there is no need to "add back" things unless something 
has been removed during the porting (highly unlikely).

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20091210/63d5e7ce/attachment.sig>
-------------- next part --------------
___________________________________________________
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.