[kde-edu]: Step without kdelibs? Conclusion
Torsten Rahn
rahn at kde.org
Fri Feb 12 10:57:02 CET 2010
Hi,
I feel as "the Marble guy" I should speak up because there are a lot of ad-hoc
statements being made in the whole discussion and I think it falls
short on answering the question.
First and foremost: Are lots of dependencies bad? The right answer is: it
depends.
A very limited amount of dependencies often enough has got its advantages
because it
* makes the API more consistent
* makes the Design easier to grasp.
* reduces the burden of porting to other platforms.
* reduces the headaches for packaging and deployment
If you ever tried to port some piece of code to some esoteric (maybe embedded)
plattform or if you wanted to create a nice library then this won't be a secret
to you. And of course this is the reason why Qt itself is a all-in-one package
itself (and why it ships with thirdparty-libs included and avoids other libs
like boost just to enhance functionality at expense of API consistency).
So the amount of dependencies should always be chosen carefully and wisely. And
you need to weigh the advantages of using a library against the disadvantages of
using a library:
* On one hand it hardly makes sense to use a big library that isn't as portable
as the other libraries in your application just for the sake of a single small
bit of functionality that it provides and that can get reimplemented quickly.
* On the other hand it makes little sense to reinvent the wheel when the
library you are trying to avoid would make your development much more easy and
would accelerate your development.
Now in KDE you'll basically find two kinds of projects:
1. Some "base technology" projects which are very low level in terms of
development focus (basic frameworks or single widgets). These projects maybe
deal 99% with backend technology and 1% with the UI.
They basically deal with stuff on the same level as Qt itself and hence it
doesn't surprise that often enough they just depend on Qt. For these projects
KDE has usually nothing to offer because KDE is mostly about making pure UI
development easier and about integration with the KDE desktop. A strong
dependency on KDE for these projects (or at least their backendtechnology) would
rather be a disadvantage, since it might be interesting to be able to port the
code to plattforms that are very well supported by Qt but not by KDE.
The Marble framework (libmarble), Phonon, Akonadi, Strigi and Soprano fall into
this category.
2. "UI-heavy applications" where 80-90% of the code is about dealing with the UI
(like buttons, dialogs, ui-components, etc.). And not just focussed on a single
widget (like a map widget) but where it's about making many widget components
play well together.
For these applications a kdelibs dependency has got a lot to offer. Not depending
on KDE for these kinds of applications would really be foolish.
From my point of view KDevelop, Dolphin, Plasma, Kate and Parley might be good
examples for this kind of category.
Often enough you'll find the category 1. ends up in kdesupport. And it is planned
to move the Marble library (and the very thin Qt application which serves as an
"example" application that uses libmarble) into kdesupport.
Note however that this is rather an exception and not the rule. And usually kde-
edu should just contain KDE applications (while Qt-Only frameworks should rather
go into kdesupport).
Now does Step qualify as such an exception? I can't tell for sure since I
haven't looked much into the topic. But my feeling is that Step is a great
application with a great canvas. But the Step canvas itself has (up to my
knowledge) little to offer for other applications than Step itself. I do
understand why the canvas is based on Qt-only (since KDE doesn't have much to
offer when it comes to the development of a pure graphics canvas).
But I do not see the case for separating UI and backend across modules.
So I agree with Anne-Marie, Tomas and Albert here that a Qt-Only Step doesn't
make sense for the reasons given above.
Best Regards,
Torsten
On Freitag 12 Februar 2010 10:52:29 Anne-Marie Mahfouf wrote:
> Hi,
>
> Just a remainder: the KDE-Edu project is for KDE based programs i.e. ones
> that use kdelibs.
> You can do a Qt-only based Step but it won't get included in KDE-Edu.
> Marble was an exception and there's no way this exception will be extended
> (last I heard, I was told the Qt part would be moved if I remember well). I
> don't see any use cases for a Qt Step when there's a KDE one.
>
> All your theory about kdelibs being too big a dependency is non valid.
> Proof is that Edubuntu, probably the best known LiveCD Educational
> GNU/Linux distribution, had all KDE-Edu programs on a GNOME desktop.
> Users do not care about dependencies, they don't even know this word. You
> won't find a GNOME user using only GTK based software (and when I say user,
> I mean Joe user, not some weird geek). Especially for Free Educational
> Programs as they are few of them and they all have different dependencies.
>
> Nowadays they even run on Windows and MacOS.
>
> If you need help in porting Step to Qt, just ask your questions on the kde-
> devel mailing list.
>
> Best regards,
>
> Anne-Marie
>
> On Friday 12 February 2010 02:08:37 v_2e at ukr.net wrote:
> > Hello!
> >
> > On Thu, 11 Feb 2010 22:14:53 -0200
> >
> > Tomaz Canabrava <tumaix at gmail.com> wrote:
> > > It uses CMake for building
> > >
> > > lt uses KDE dinamic library system for easily building a dll on
> > > windows, or a .so on unix.
> > >
> > > it uses KHTML, the kde html rendering library
> > >
> > > it uses KXMLGuiWindow for building the menus and toolbars dinamically
> > > from a xml file.
> > >
> > > KDE's configuration mechanism ( KConfigXT )
> > >
> > > the core is Qt only. but the ui is heavly based on KDE stuff.
> > >
> > > take my word for it, if you think that's too much trouble to program
> > > because of the kdelibs dependency, I can take a few days to guide you
> > > througth the code till you feel confident to try.
> > >
> > > don't discard anything without trying.
> > > _______________________________________________
> > > kde-edu mailing list
> > > kde-edu at mail.kde.org
> > > https://mail.kde.org/mailman/listinfo/kde-edu
> > >
> > Hello!
> > Thank you for your explanation! :)
> > Now I can see there really is a strong kdelibs dependency, but
> >
> > writing a Qt GUI for Qt-based application seems just a question of time
> > to me.
> >
> > You may think I have nothing to do and that is why I have decided to
> >
> > "invent another bicycle". But this is not true. At least, this is not
> > completely true. I do have my regular work to do and I don't have much
> > time to spend for my hobby-programming, but I do like the idea of "the
> > only dependency". Besides, like I have already mentioned, I have a
> > number of friends who uses GNU/Linux operating system. Not everyone of
> > them uses KDE. And the problem is not only that those who don't use
> > KDE as their everyday desktop environment do not want to install "any
> > part of KDE", but the fact is that not everyone who does use KDE every
> > day knows about KDE-Edu project. I'm serious. I had been using KDE for
> > a couple of years and I have learnt about KDE-Edu project existence
> > only after stopping using KDE on my PC (that is about few months ago)!
> >
> > Now I can see a lot of very nice and very useful (!) programs inside
> >
> > of KDE-Edu project and I would like to help developing them and
> > presenting them to people who doesn't know about it yet.
> >
> > Still, there is a strong belief among many people I know that "if I
> >
> > use Gnome - I need only Gnome's libraries and I do not want any other
> > libraries; if I use KDE - I want to see only KDE libraries on my system
> > and do not want to see any other and so on". At the same time I know
> > that every one of my friends has both Qt and GTK libraries
> > installed on his/her machine. That is why they won't even hesitate
> > installing such great programs on their machines knowing that those
> > programs has only one dependency (it would be ideal) and that that only
> > dependency has been satisfied "a priori" on their PC.
> >
> > I believe it would be great and it will help spreading an information
> >
> > about KDE-Edu project and will surely attract some new users and
> > developers to it. I cannot see anything bad in it.
> >
> > Now, talking about a technical side of a question, as now I know
> >
> > there is no possibility to use Step without kdelibs so far, I think I
> > should do the following:
> > 1. install Step and get into its source code;
> > 2. find "KDE-dependent" pieces of source code there;
> > 3. think about the possible ways to implement the same (or very similar)
> > functionality without using kdelibs;
> > 4. in case of successful finding such ways, try to reimplement all the
> > necessary pieces one by one - step by step.
> >
> > I will definitely need some help from the people familiar with Step's
> >
> > source code at least during stages 2 and 3.
> >
> > But I will be grateful for any help, useful information and advices
> >
> > at any time!
> >
> > By the way, I know about a possibility to make a "fork" of the
> >
> > project and do whatever I want there, but to be honest, I do not like
> > such behaviour and I do not want to do that. But even if I did, my
> > "programming power" is definitely not enough to maintain such a
> > project. That is why, most of all, I would like this program (if it
> > becomes a reality) to be a part of KDE-Edu project. I think, this is
> > the only way to help each other.
> >
> > I must note that when I say that I always keep in mind Marble. I
> >
> > think it's just an excellent program and an excellent idea to make it
> > useful with- and without KDE dependencies. I like it very much and
> > that's why I would like to spread this idea on some other useful
> > software. :)
> >
> > Hope, you understand my reasons a little better now.
> >
> > Regards,
> > Vladimir.
> >
> > -----
> >
> > <v_2e at ukr.net>
> >
> > _______________________________________________
> > kde-edu mailing list
> > kde-edu at mail.kde.org
> > https://mail.kde.org/mailman/listinfo/kde-edu
>
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu
--
Torsten Rahn
Senior Consultant
basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 3969-961 | Fax: -736|
torsten.rahn at basyskom.de | www.basyskom.de
Handelsregister: Darmstadt HRB 9352
Geschaeftsfuehrung: Eva Brucherseifer
More information about the kde-edu
mailing list