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