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

List:       kde-devel
Subject:    Re: KProprietary
From:       Klaus Sonnenleiter <klaus () m-machine ! com>
Date:       2000-08-05 16:42:09
[Download RAW message or body]

Jono,

I think you're right: There is no point in enforcing an ultra-dogmatic rule that
positions KDevelop in the "for-FSF-type-software-only" category. It would only make
developers who have a more traditional background uncomfortable and more likely to
switch to products like Kylix once they become available.

However, I don't quite see the point of this discussion either - can't you just
create a class myAboutData that inherits from KAboutData and then override whatever
you need?

Klaus Sonnenleiter
The Media Machine, LLC
http://www.m-machine.com

Jono Bacon wrote:

> Quoting Matthias Belitz <matthias.belitz@gmx.net>:
> > please tell me, why there should be anything like this ?
> > I guess, every commercial developer will have his own license, and his
> > ownideas how this dialog should look like.
> > And it is still possible, to do not use the standard KDE Help/About menu
> > entries ...
> > So I think, when they want to earn money with and develop some packages,
> > they dont care, if there is a preconfigured KAboutData ...
> >
> > The KDE team should have especially  the free developers in mind, others
> > will come , if the market is big enough (and it will be !!!)
>
> Although I agree that KDE should promote the development of free software, it
> should not be mandatory. I fully believe that support for commercial vendors
> should be included.
>
> Cheers,
>
>             Jono
>
> --------------------------------------
> Jono Bacon - [vmlinuz] -- jono@kde.org
> Qt/KDE Developer - Founder of Linux UK
> --------------------------------------
>
> -------------------------------------------------
> This mail sent through IMP: mail.wlv.ac.uk
>
> >> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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