Why KDE4 is called KDE?

[Draciron Smith]

To answer earlier posts first. Kmenu does NOT find most apps. They
have to be configured with a .desktop to be found and also have to not
be "KDE specirfic" as Kevin also pointed out. That means lots of apps
are not found.

For the 20th time. Console apps CANNOT be found using the menu adding
function as they are not menu items to start with unless you create
your own custom .desktop file for each and every one of them.

As I've pointed out repeatedly Krunner really offers no functionality
not availible from a command line. It is essentially an ecapsulated
command line which might be great for some but is nothing close to the
functionality I rely on. Clearly KDE lost a great deal of
configurability and no matter how many times people say well you can
go back to doing it the pre-KDE way that doesn't change the fact that
KDE lost functionality and customization.

Now on to Kevin's comments.

On Thu, Dec 10, 2009 at 2:21 PM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
> 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.


That is true today primarily because VC.NET as these apps have been
forced to migrate off of VC++ to the .NET as that is THE ONLY place
essential functionality is exposed from.  Wasn't that long ago
actually that the majority of big commercial apps for windoze were
written in Borland C, M$ got mad and delibertely bankrupted Borland
and all but ended Borland's compilers with intentional efforts to
exclude Borland compiled apps and pressure on downstream vendors.  Big
commercial server software as you mention is only a fraction of what
is commonly on desktops. You go to a bank they use dozens of apps
written in Delphi, VB, a real estate agent, an insurance adjuster and
so on.  The VC.NET stuff is generally only the basics, the real work
is usually done on Delphi and VB apps. You also see an amazing amount
of Access stuff out there too, even today.

> 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 is actually. Gambas is what VB should have been. Personally I
loved coding in VB. It had until VB 6 the most user friendly and
advanced IDE I'd ever used, the syntax was easy to learn and you could
rip out massive amounts of clean well document code in a very short
time. I wrote entire suites of software in 60-90 days including spec
gathering, setting up test networks, designin schemas, testing and
debugging. Using C or C++ the same apps would have taken me a coulpe
years to write even if fully profficient.

Then reality sinks in when you distribute a VB app. FIrst there's that
nagging run time lib that M$ in it's infinte wisdom ceased putting a
version into after ver 4. So VB 6 apps would knock out VB 5 apps and
vice versa.  It was nearly impossible to install on any desktop
without knocking out half the apps they ran once VB 6 came out.

The code was slow, consumed large amounts of space and prone to
conflict with VC apps at times as well. VC also relies on run time
libs and like VB isn't truely a compiled language. VB, VC, VFP all use
some of the same run time libs and frequently I had to track down what
run time libs went with which app and install them locally to prevent
conflicts. I also modified install scripts to install my run time libs
locally to keep from getting blasted the first time somebody installed
another Visual studio compiled product.

Gambas loses those problems. Gambas also has full support for console
based apps, a very weak spot for VB. Yes you could compile a console
based app but it really lived halfway between console and GUI. Gambas
you can compile a RT console app.

The IDE for Gambas heavily mirrors the VB 5 IDE but with many improvements.

Aside from Gambas WXBasic and the .NET clone are other good
alternates. Most of these actually have better code portability from
old VB apps than .NET and VB coders have to relearn far less jumping
to Gambas than they do using .NET. So there IS a great VB equiv in
Linux. It's just not often in the default distro and folks haven't
heard much from it yet. I'm writing my writer's editor in Gambas both
because it'll be quicker and too teach myself Gambas. Been several
years since I wrote a VB app so I'm a might rusty LOL.

Another big advantage to Gambas over VB is you can access the system
without making the arcane win32.dlll calls. I actually still have a
cop of Dan Appman's Win32 API Bible for VB. Well worn but I keep it
for sentimental reasons. Gambas exposes Linux functionality without
the ordeal that was using system calls in VB. So it has the power of C
but without the security woes, hassles of managing memory, or the
archaec syntax features like the semi-colon too end a line. No
compiling then looking back up sometimes as many as 60 lines before to
figure out where you improperly put a semi-colen or forgot one or
where you forgot to close a bracket. You get the err msg on the exact
offending line and get auto completion for many items. Makes coding a
breeze and focuses you on program logic not syntax.


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

WXBasic has full cross platform support and same with the .NET clone.
Gambas is really a Linux product. There is hopes for portability to
windoze but support for other OS's is quite poor.  I haven't tried
RealBasic. Will have too look it up sometime and give it a look.

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

I've been trying to get funding for years to advertise just such
migrations. Wouldn't take much to build a test environment and take
real world VB code and build Linux replacements for it. Porting the
back end is often a bigger issue as SQL Server's not quite ANSI SQL
and it's odd database design can be time consuming too port and so
many of them still use Access DBs. I'm amazed at how often I've been
called in to fix an Access DB when the problem wasn't IN the DB it was
THE DB and that it was being overtaxed way beyond what it was designed
to handle. Developers who knew no SQL would instead turn to Access and
what they built worked  albiet rather slowly until the data grew and
grew and eventually overwhelmed Access. Generally I was able to port
it out too MySQL, streamline the schema and rewrite the SQL and left
happy campers in me wake.

Need about a mill for advertising and to hire a few employees to
really make a serious go at it. Could be profitable in 6-12 months but
could have make a fortune if I could have been funded 3 or 4 yrs ago
when the real crisis happened. Today most VB installs are a strange
mix of VB, .vb.net and other apps with SQL Server, MySQL and Access
backends strewn about haphazardly, often depending on each other with
bizarre data propogation methods that at a glance just plain shouldn't
work LOL.

Basic idea is simple. Show them how they can save their code base and
coder's skills as well as switching to cheaper, more efficient more
secure Linux servers which also expand their capabilities. The sell is
cheaper, that's really all that reaches the execs, selling the IT
staff is mostly overcoming their fear of Linux and showing them a
desktop with lots of cool reasons they'd want to use it but that they
can instantly be productive in without training. KDE used to be a key
part of my demo on that. I'm kinda lost with KDE 4 as much of the
things I'd demo too potential Linux converts is gone from KDE or so
much harder too do there is no way I'd demo that. It'd send them
screaming into the night. So my whole desktop presentation is shot.

Still a viable idea and Vista so disgusted so many windoze users and
has very low adoption rates in the corporate world that moving to
Linux was openly talked about even in very heavy Microserf shops.
Windows 7 though has given them new hope, though I think it'll be
dashed. I have full confidence M$ and it's vindictive streak will
punish users for rejecting Vista in some way with Windows 7.


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

Nope Delphi has very strong bastions, one is contact management
software. Back in the late 90s I was a project manager for a VAR and 2
of the top 3 contact management suites were written in Delphi, the
other one was written in VB. Did a contract a few years back and
discovered how deeply Delphi penetrated the mom and pop hardware
industry, as another example. VAR stuff and middle ware is really
Delphi territory. Delphi is more powerful than VB and almost as
friendly to code in. Delpi offered a free and powerful DB that was
basically maintence free long before MySQL gained market penetration.
This was a big edge for Delphi and I'm sure many have since switched
to MySQL but kept Delphi if nothing else because of the existing code
base.  Accounting software, some banking software, lots of little
niche areas like that Delphi has really established itself.

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

Yup ! It DOES. That's why I've been advocating putting it in the
default distros. It empowers the avg user to write some very
sophisticated programs on Linux but without the security worries that
come with C based syntax from buffer overruns and failure to check
input string lenghts.  Gambas handles memory allocation and just
truncates or errs out on strings that are too long. If you can buffer
overrun a Gambas program it's a vulnerability in the Gambas libs not
in the end user App. The fix is as simple as fixing the libs and
recompiling the libs with the new app. So novice programmer's code
won't create endless sercurity nightmares as they would with some
other languages.

Surprisingly there is still a fanatical QB fanbase as well. Those
folks could port QB code into Gambas and write console apps. So again
an appeal to a small niche group.

So far my advocay has fallen on deaf ears. I get the Python is good
enough and if they want Gambas they can go download it. Wrong people
like me can go download it. Many of the folks who'd be most interested
in Gambas and WXBasic won't even know it's there and rarely stick
around with a Linux install long enough to find out many great apps
exist. I've been outspoken about creating a new Linux user friendly
environment to keep people who try Linux using Linux. Far too often I
hear people who try Linux, they do a default install, feel utterly
lost and never find that one or two apps that reach out and grab them
and generate the necessary interest to tackle the learning curve
needed to convert to Linux. Get folks past that hump and they rarely
go back to windoze. Most of the converts I lose I lose in the first
day or two of running Linux and I lose them because of the default
apps isntalled and because they see nothing in the default installs
that they can't do in Windoze. Much of the value and power of Linux
isn't imediately obvious to a new user. That's why I've pushed for
loading default installs with apps like Gambas, K3b, Open Office,
Rekall, Pidgin, etc. There isn't much that can be done for non-OSS
formats except make it as easy as possible too add that support in.
Key thing is have them up and running ASAP. Get them doing most things
with a minimal learning curve and they stick around long enough to ask
how to do other stuff.

It is also why I've been a very outspoken critic of most default
package managers. The jokes that come with Fedora, Ubuntu, OpenSUSE,
etc. Come on that's a 1980s package manager. Kyum, Yumex, Gnome-Yum,
Synaptics, Kpackagermanager, and so on. THAT is an immediate slap you
in the face this is COOL! Kinda thing. Especially once they get the
real repositories added that let them add in ugly plugins and stuff.
Man every time I pull up Yumex I'm like a kid in a candy store LOL. I
download thousands of apps and use many of them, though there are
always lots I install meaning to try and never remember or that I try
and discover they are not really ready for prime time.

KDE used to be the centerpiece of how I demostrated the superiority of
Linux too a windoze user. Yes I spend a great deal of time at this.
Converting at least a dozen a year and getting sometimes as many as
100 a year to give Linux a try. I then often spend many hours helping
them with various issues. I know their hooked when they ask me how to
install a tarball. That means they've gone outside the repositories
I've set up for them and starting downloading software of interest too
them not supported on their distro.  I have zero confidence in KDE 4.x
converting anybody. Hell I can't find anything in it, how's a fresh
windoze convert going too?

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

I tried Kylix and it wasn't a bad language. Pity it died off. I'd used
it more but I'd already converted more the the sys admin/network
security world by then.

Real pity about Borland too. They made some of the best compilers of
their time. Borland C was long a standard of mine though I would often
compile in Watcom. Their IDE sucked but Watcom gave you the tightest
code of all the ciompilers at the time.

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

I haven't looked at in in a few years, probably several but last time
I looked FreePascal was really more TurboPascal ver 5. It lacked all
the later features of Turbo Pascal and really didn;t compare to Delphi
at all.  Don't get me wrong, I'm sure it's a great compiler for old
school Pascal stuff and gawd knows I wrote lots of DOS based Pascal
code. The incompatability starting at Turbo Pascal 6 I think it was
which rendered all my libs and my codebase useless caused me to drop
Pascal. I just wasn't going to go through the effort to port all that.
Sides I was getting paid good money to program in Xbase, PDS7 and C.
Still had lots of that old Pascal code sitting around on 20 yr old
floppies LOL. Went through tens of thousands of floppies a few years
ago, saved a little but mostly trashed the rest and tossed the
floppies.

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

Far as I can tell it's not really heavily used yet for in house stuff.
A few years ago connectivity to even MySQL was so so and lots of
important functionality was still either not there or not real stable.
I first heard of Gambas about 4 years ago. Began playing with it but
haven't really written any large apps in it. Did port some old VB code
I had laying around and was amazed at how little I had to change.
Right now Gambas is I feel ready for prime time and a rising power.
Just as 10 yrs ago you saw almost no Python code in repositories,
mostly people scripted in Python. It lacked too many essential
capabilities to write anything major in it. Today Id oubt there's a
major distro without at least a few Python apps in the default distro.
In a few years you'll start seeing Gambas apps showing up in
repositories.

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

Yup, QT support, DB support and such were what let Python and Perl
graduate from scripting languages to a language where people wrote
serious apps in. The same support has arrived finally in Gambas,
WXBasic, etc. I think Ruby now has QT support also and a growing fan
base. There are several others and Rekall might surprise a few folks 5
yrs down the road.


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

Not really. Python gained QT support what about 5 yrs ago? I wrote
more than a few Python scripts several years ago and don't remember
seeing anything like QT support. MySQL support was done throgh
openODBC rather than native drivers if I rememebr correctly. There was
lots missing from Python and Python was looked down upon by distro
maintainers as not a real language. Today it's all over the place.  I
recently converted a lady in Oz to Python and introduced her to Linux.
She was quickly able to start writing primitve programs in Python.
Against my advice she also tried Java but hasn't gotten much more than
hello world working in Java.

Give it time and get it in default distros. I'd bet %75 of the people
reading this list had never heard of Gambas before reading this.
Gambas, Python, Ruby those really need to be part of the default
distros. Something that's already there rather than something people
hear about a couple years after the start using 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).

I remember Kbasic. It had good potential but it was nowhere near ready
for primetime. I still have the source for Kbasic somewhere. I was
disapointed when it was killed off as a project.

As a rule of thumb, 5 yrs is a good ruler for the progress of a
language from the time it is able to do HTML, make sys calls, call
console apps, talk to DBs without using third party drivers, use GTK
and or QT, good support for things like sound, graphics, etc.
Basically until it's ready for prime time. Then give it 5 years to
catch on. After that you'll start seeing apps appear for general use.
That puts Gambas on pace for about 2012 or so to really have an
impact. Took Python many years. Python came out what in 95?  It was
commonly availible in the early 2000s and really didn't take off until
around 2005 or so. Most python scripts in 2000 were parsing scripts
and stuff folks didn't want to use Perl for. I found Python much
easier to use than Perl so I'd use Rexx or Python for system scripts
most of the time. Then around 2003ish I started seeing apps show up
that used Python. Around 2005 I was installing tarballs of Python
apps. Today it's making inroads but it took almost 12 years to really
get established. Ruby came out I think around 99. That's around the
time I first heard of it. It's also finally taking off though I am not
aware of anything in any distro that's written in Ruby.


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

I was specifically talking about Kwrite at that point, however
shouldn't be too hard to buid such bindings if they don't already
exist for other languages. You have a good point about the bindings
and it is one of the reasons why Linux apps are usually so small.
Folks just play don't reinvent the wheel. They build on functionality
already out there. The downside is some dependencies.

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

Now THAT is music to me ears :)  That is the part I'm really
interested in. I'd have to build upon that basic functionality but
I've written editors before even small script interpeters and it's
tedious and involved work. Amazing how complex little things like
keeping track of the cursor can be :)  Now I really need to look
deeper into that and it also makes reviving Kedit more feasible. If
Kdevelop ported it then they've done the worst of the work already.
Not sure that Kedit needs any new features. A large part of it's
appeal is simplicity and how light weight it is.


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

Which is an excellent suggestion. I think a workable suggestion as
well. I agree almost all the complaints center around those 2 projects
and it deffinitely covers my problems with KDE 4.


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

Which again would be a big plus. Gnome's big lack in my opinion are
those very same features lost in in the KDE 3.x to KDE 4.x migration.
The change over disolved any difference I see between Gnome and KDE.
Following your suggesions gives Gnome users a chance to enjoy what was
once KDE specific power.

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

Again a very good point.


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

That happens and at some point you always have to sit down and rewrite
stuff. Even code you wrote yourself, several years later you finally
get mad enough at it that you rip entire sections out and redo them.
Just a byproduct of coding.

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

Really is time for me to spend some time looking at the code.

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

Quite true.

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

You've shed new light on the mess, so I recant part of that. Though i
still have a bone to pick with the folks that made some of the
decisions :)

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

No idea. I never had call to really follow the workings of KDE. It
just worked and worked wonderfully.  It was the ONE thing I could
introduce new LInux users too and not have to hand hold them at all.
In fact KDE energized them and gave them confidence. They quickly
picked up on how to do stuff and I was answering less obvious stuff
and suggesting apps for them to try for various tasks and such.

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

I'm sure enough searching I'll find the code. Again shouldn't be too
hard to split it off Kdevelop either, more a matter of removing
functionality and adding the spell checker back in.

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

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

It solves all the problems and again I thank you for a very good
solution too a problem that has vexed the community quite a bit.

>
> 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.
>
> My guess would be that there is no need to "add back" things unless something
> has been removed during the porting (highly unlikely).

There is missing functionality, I mean it's not just in a different
place it's completely gone. However should be quite easy to use the
same methods that drag and dropping a menu item do combined with the
kicker interface and you can restore right click add ANY app in
seconds to the panel.  Somebody familiuer with KDE code could do it in
minutes I suspect. It'll probably take me weeks but will be well worth
it.

> Cheers,
> Kevin
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring


Not sure who said the deal about submitting bug fixes when it came to
my tweaks being obliterated. I wasn't talking about fixing bugs I was
adding features, customizations and functionality.  Little of it
though would have had large appeal so it's unlikely that anybody would
want it contributed. Much of it was unique to the environment I was
in. The odd little work arounds we had to go through to get around
obstacles too productivity placed by Beurcrats who read one too many
PC magazine and thought they were experts because of that article LOL.
___________________________________________________
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.