Hello all,
I would welcome this dependency a lot. I would definitely note signals
and slots mechanism as one of the most important ones -e.g. writing and
connecting itk events is just plain annoying.
One of course could think that the amount of work to get rid of this
dependency in case Qt suddenly changes its licensing policy would be
immense (it kind of differs from other open-sources projects in the way
it developed), but given the project changed like 3-4 owners since going
open source and it still has an LGPL version, I doubt it would happen.
Just one more thing - seems like CMake-Qt interaction is also getting
better - cmake modules being included as part of distribution of Qt and
automoc support in later versions of CMake all seem to simplify the
Qt-related builds and make them more robust.
Overall, +1 for Qt from me :)
Rostislav.
On 15/12/2014 00:20, Taylor Braun-Jones wrote:
Hi Sascha,
Thanks for the response. I agree - there are lots of points to think
about...
On Sun, Nov 30, 2014 at 6:30 PM, Sascha Zelzer
<[email protected] <mailto:[email protected]>> wrote:
1. What functionality is required within the core to fulfill its
role as a foundational library and how does an external library
support fulfilling that requirement.
Initially many of the features of Qt Core would simply replace
existing MITK implementations with something equivalent or better.
From the Qt Core documentation page[1], here are some of the most
applicable features to fulfilling the role of MITK Core as a
foundational library:
- signals/slots
- property system
- a rich suite of container classes that are often more performant and
full-featured than their C++ Standard Library equivalents
- full-featured suite of threading classes
- including a high-level abstraction in Qt Concurrent (map, reduce,
QFuture, etc)
- state machine framework
- data serialization
- various utility classes such as:
- QFileSystemWatcher
- QStorageInfo
- QTimer
- QCache
- QAtomicInteger
- QStandardPaths
But most importantly, all this functionality is supported across a
broad range of platforms - all the ones MITK already supports, but
also all the major mobile platforms that MITK will hopefully support
in the future. Even bare metal is an option.
2. Would all stakeholders accept an additional hard dependency or
can that dependency be moved into a separate module allowing
higher flexibility.
I would be okay with the additional hard dependency. How about other
MITK users out there?
3. Does the license restrict current or envisioned use cases.
The people who would be affected currently are those using MITK to
build an application that:
(1) Does not use Qt
(2) Is closed source
(3) Is statically linked
For current use cases, I think the number of stakeholders who fall
into this category is quite small (maybe even zero?)
For envisioned use cases I'll assume, for the sake of discussion, MITK
plans to support the two biggest mobile platforms at some point in the
medium term. IMO, supporting just Linux/Mac/Windows is not enough
anymore since developing medical imaging applications on tablets has
value and tablet platforms are dominated by Android and iOS. Thanks to
Apple's App Store policy (not a technical limitation of iOS)
applications distributed with dynamically linked applications are not
allowed. So now you have this catch 22: in order to support as many as
5 different platforms, using a abstraction library like Qt that
supports a broad range of platforms becomes very appealing - but by
adopting Qt in MITK Core it's now impossible to deploy MITK-based,
closed source apps for iOS through the App Store. At least that's my
understanding. Please correct me if I'm wrong.
4. What (if any) overlap in terms of functionality exists with
current dependencies.
Qt definitely overlaps with some of the abstraction layers provided by
ITK, but in general, I think the Qt versions tend to be better/more
complete. For example, ITK is missing a readers/writer lock which Qt
provides with QReadWriteLock, QReadLocker, and QWriteLocker.
As a summary, the decision about additional core dependencies
needs to take many different aspects into account. In my opinion
the most important ones are concrete requirements, licensing
issues and community acceptance.
Any other MITK users care to voice an opinion? How would adding Qt as
a hard MITK dependency affect you?
Best,
Taylor
[1] http://doc.qt.io/qt-5/qtcore-index.html
On Sun, Nov 30, 2014 at 6:30 PM, Sascha Zelzer
<[email protected] <mailto:[email protected]>> wrote:
Hi Taylor,
we always welcome these kind of discussions containing good
arguments and feedback / opinions from the community.
You are right that one of the main original points for not using
Qt in the Core was the GUI Toolkit agnostic architecture. As you
said, Qt went through a thorough modularization process with
version 5 which alone would validate revisiting that design choice.
For a MITK Core dependency, we need to consider several points. I
will try to summarize them shortly below, but this list is not
authoritative in a sense that it is compiled out of memory based
on discussions of the MITK developers (we should write them down
and formalize this):
1. What functionality is required within the core to fulfill its
role as a foundational library and how does an external library
support fulfilling that requirement.
2. Would all stakeholders accept an additional hard dependency or
can that dependency be moved into a separate module allowing
higher flexibility.
3. Does the license restrict current or envisioned use cases.
4. What (if any) overlap in terms of functionality exists with
current dependencies.
Your point about using Q_PROPERTY and the Qt meta-object system in
general to ease the integration with other Qt base MITK modules is
definitely an argument to be considered (point 1). It would be a
far-reaching design decision for the MITK Core. On the other hand,
I am currently not aware of any pressing issues which would
require considerably more effort if the MITK Core is kept Qt-free.
Of course, also point 4 would need not be considered. Hence one
question would be:
What Qt features would be beneficial for the whole MITK eco-system
and what are the trade-offs when supporting these features in the
Core directly compared to "decorating" it with another layer (module).
In the case of Qt, the license has always been one of the most
discussed issues. AFAIK Qt is now triple-licensed (which seems to
be a good thing). However, it still requires a commercial license
for closed-source projects which want to statically link to Qt.
Although the MITK build system support for static linking was not
always kept up-to-date over time we still consider static linking
as an important feature of MITK applications (not the Workbench
necessarily). A hard Qt dependency would be a departure from that
philosophy (for closed source projects).
As a summary, the decision about additional core dependencies
needs to take many different aspects into account. In my opinion
the most important ones are concrete requirements, licensing
issues and community acceptance.
Best,
Sascha
On 11/20/2014 04:05 PM, Taylor Braun-Jones wrote:
I know this idea has been discussed before, but now that MITK
is beginning to make the transition to Qt5, I think it's valid
to revisit the discussion.
MITK Core currently does not allow any dependency on Qt
because MITK Core is meant to be GUI toolkit agnostic (correct
me if I don't have the rationale correct). Given the
monolithic architecture of Qt4, I think this policy made
sense. However, with the more modular architecture of Qt5, it
is now possible to use just Qt Core in MITK Core and remain
GUI toolkit agnostic. Being comfortable with the fact that
this dependency, despite having "Qt" in the name, is not
GUI-specific just takes a little getting used to :-)
The advantage is that Qt Core provides a broad, high-quality
suite of cross-platform abstractions that support all the
platforms MITK currently targets - plus some platforms that I
hope MITK would consider targeting at some point in the future
like Android or iOS. With the OpenGL rendering improvements
coming soon in VTK[1], running MITK-based applications on
Android- or iOS-based devices will be feasible and useful for
certain applications. Regardless of whether the application
GUI were developed using the native Android/iOS SDK or using
Qt Quick, having access to Qt Core for the platform
abstraction would be beneficial.
Secondly, being able to use Q_PROPERTY and qRegisterMetaType
in core classes like mitk::DataNode and mitk::DataStorage
simplifies integration with Qt-based GUIs, especially Qt
Quick-based ones.
I'm curious to hear what the the rest of the MITK team and
community thinks about this idea.
Regards,
Taylor
[1] http://www.kitware.com/source/home/post/144
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
