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=157005751&iu=/4140/ostg.clktrk _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
