[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Qt-only KDE applications
From:       aleXXX <alexander.neundorf () gmx ! net>
Date:       2002-01-25 0:15:48
[Download RAW message or body]

On Thursday 24 January 2002 18:27, Simon Hausmann wrote:
> On Wed, Jan 23, 2002 at 05:59:04AM -0500, Benjamin Meyer wrote:
>
> > TrollTech will be releasing a non-commercial windows 3.0 license. Who
> > says they have to? Who says they have to release 3.1. (just go and try to
> > get the mac version...) If anything the non-commercial package is
> > probably hurting them financially in the market that they are making
> > money mostly in (windows duh) and if I was in the marketing department I
...
>
> Guessing, guessing, guessing :)

I don't think they make the most money in windows, they probably make the 
money from commercial licences, probably more Unix only and crossplatfrom 
than Win only. 
People, who use only windows will choose either VB, Delphi or MS/Borland C++.
They won't even think about using Qt, they don't know that it exists.

> >  Let us now look at the alternative. This alternative it to clean up
> > kdelibs so that it will port on windows (and mac?). We are not talking
> > about the kdebase, but kdelibs. This will require the code to be gone
> > over and cleaned up to be more compliant etc which will also practicly be
> > a code review. Doing this will be worth its weight in gold. You want to
> > know why? Because then all of the little qt-only developers will then see
> > that they can get all of the kde functionality (not just the stuff in the
> > qt/kdelib) and still have cross platform compatibility. They will then
> > care more about kde, help out with it etc. <off topic> Heck with kdelibs
> > ported someone might port kdebase! How cool would it be to have the kde
> > desktop on windows? Porting kdebase would be more work, but something
> > that can be done. </off topic> Trolltech did most of the work with
> > abstracting qt and it only makes sense to try to get kdelibs for windows
> > first. I am surprised that someone hasn't tried already. And I
>
> I think there are multiple reasons why noone hasn't tried, yet.
>
> a) it is a painful platform IMHO (msvc++ has so many embarassing
>    compiler bugs that it's not funny anymore, but maybe I'm just
>    fastidious ;)
>
> b) porting requires knowledge. Complete knowledge about kdelibs,
>    knowledge about lots of the base unix APIs, knowledge about Qt
>    (including internals, as not few parts of kdelibs rely on
>    internal Qt stuff) and last but not least win32 to a certain
>    degree.

And may I add an important point: 

You get *much* more support on Unix, free as in free as beer ;-)
There are much more people developing for Unix, which have some "deeper" 
knowledge, e.g. about compiler problems, linking, and such things.
Try to find somebody who programs under win and knows which format the 
libraries under windows have or which compiler flag you need for something. 
You will find much less developers, due to the fact that MS hides everything 
behind a point-and-click interface and that there is no such community as 
there is in open source.
Most of the people under win work closed source, they can't give away the 
source, they can't work together on it, they don't communicate, they don't 
share and increase their knowledge. In a big german company code isn't even 
shared between different departments, they exchange only binaries, so, how 
could they learn from each other ? Everybody has to pretend that he is able 
to do everything *perfect*, he can't say, "Hmm, I don't know, have a look, 
how can I do it better ?" because this would mean "I'm to stupid for my job".

> c) Money. You have to pay $$$ for the compiler.
>    (yes, you can get the borland compiler as commandline tool for
>    free but the non-commercial edition of qt/win doesn't work with
>    bcc but requires msvc++)

Yes, even companies (the same as above) almost can't afford it to install 
msvc++ for everybody who would like to have it, only if he has a really good 
reason. It's ridiculous.

People who want to write code and want to have it used by others will do it 
under Linux/Unix, there is simply no such "infrastructure" for distributing 
self-made code under windows.
Windows users use their copies of commercial apps (wherever they come from) 
and copies of other apps, for which they also don't pay (e.g. winzip).
There is no app site where they go to and look for what new apps might have 
appeared. 
I think if today somebody wants to write a program, he will do it for his 
favourite desktop env. If he uses KDE, he will start learning Qt and if he 
wants to he will turn it into a KDE app, since KDE is what he uses all day 
long and since it is more or less the default linux desktop at least here in 
germany (thanks Suse). The possibility to have his own app installed by 
default by a major distribution is a *huge* motivation, and this can be 
achieved best if it is a part of KDE.

> > hear that person in the back who says kde-cygwin is here. Here I am
> > laughing back at you. Tell any average person that you have to install an
> > "emulator" to run the app and they will almost laugh at you too. cygwin
> > is not the answer. Qt runs natively on windows so why can't kdelibs? Also
> > we would also be relying on 2 other sources (qt and cygwin) for
> > portability. Having it be as simply as a recompile is a much better
> > solution.
>
> I agree that cygwin probably not a solution for users.

Only want to note: cygwin is great, the only way to make working under 
windows (if you don't have the choice) acceptable.

> >  Lets talk about new developer. How about commercial developers? They all
> > only use qt and don't even think about using kde. <insert ovious (sp?)
> > reasons>

Yes, portability if required.
But honestly, the problem that kde hasn't been ported to windows isn't that 
everybody thinks this would be a bad thing. The problem is, that nobody has 
done it until now, for the reasons mentioned above.
Port it and nobody will complain.

Bye
Alex
[prev in list] [next in list] [prev in thread] [next in thread]