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

List:       kde-edu-devel
Subject:    Re: [kde-edu]: Step without kdelibs? Conclusion
From:       Vladimir Kuznetsov <ks.vladimir () gmail ! com>
Date:       2010-02-12 13:06:01
Message-ID: dbce82dd1002120506w2ad611c0h1922824ac135f054 () mail ! gmail ! com
[Download RAW message or body]

Hello,

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

Actually Step do consist of an UI and a backend, but separation is not
on a level of a canvas. Step backend is a physical simulation library
(StepCore) which is a pure mathematical thing and is unrelated to any
drawing (just like other similar libraries, namely ODE, Bullet, etc.).
It has only a slight QtCore dependency (namely it uses QVariant which
I want to replace btw) and no KDE dependency at all.

Step front-end is a KDE application which includes both graphical
canvas and widgets. Step front-end do benefit from both using kdelibs
and being part of KDE-edu project, and I hope this is not going to
change :)

> So I agree with Anne-Marie, Tomas and Albert here that a Qt-Only Step doesn't
> make sense for the reasons given above.

For sure I also agree with this.

-- 
  Best Regards,
   Vladimir Kuznetsov
_______________________________________________
kde-edu mailing list
kde-edu@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
[prev in list] [next in list] [prev in thread] [next in thread]