[Rock-dev] splitting rock-widget-collection

[Sylvain Joyeux]

On 05/13/2013 11:06 AM, Alexander Duda wrote:
> On 05/13/2013 10:14 AM, Sylvain Joyeux wrote:
>> On 05/13/2013 09:10 AM, Alexander Duda wrote:
>>> Hi,
>>>
>>> the rock widget collection was originally a place for qt designer
>>> widgets which are independent from any other package than qt.
>>> Unfortunately, more and more widgets were added which have dependencies
>>> to rock packages. Therefore I would like to split the
>>> rock-widget-collection into two parts.
>>
>> I don't like this 'depends on rock packages' and 'does not depend on
>> rock packages' dichotomy. This seems to be related to the external/
>> discussion to me.
>>
>> RTT-free rock packages are fine dependencies for me. They only
>> require a C++ compiler and some standard and rock libraries.
> Dependencies should only be made if they absolute necessary. In the
> case of qt designer widgets this is usually not the case for rock
> packages. For example ImageView only depends on base and frame_helper
> because there is one single conversion from our type Frame to QImage
> which is completely rock specific.
>
> In the long run I want to add our widgets to http://qt-apps.org and
> there will not be much acceptance if we have dependencies to:
>     -> base/types,
>     -> base/image_processing/frame_helper
>     -> ...
>
> Anyway, for building general widgets for me it is best practice to
> relay only on qt types in the first place otherwise the re-usability
> in other projects with different base types is not really given.
Agreed. Which is why there should be a way to only build the pure-Qt
widgets from the common_widgets package. Automatically (basically, it
will boil down to having a pkg_check_modules on the base types and
disable the widgets that need base types).

What I disagree with is this splitting of "rock widgets" vs "non-rock
widgets". As long as widgets depend only on pure-library code, they are
generic and can be reused outside of rock. Calling a package
rock-widget-collection and splitting the qt-only from the
with-non-qt-types enforces the impression that it is not the case.

As I said, this is very related to the external/ discussion. We should
stop thinking in a way that there is "rock" and "outside of rock". All
our libraries can be integrated into any C++ program without changing
any line of code, and therefore fit the very definition of "reusable
outside of rock". That's the message we need to send. When we reuse
libraries that fit that description, then they should be very much "part
of rock".

>>
>> I would prefer, as a cleanup of the widget stuff is:
>>
>>  - a common_widgets (formerly known as rock_widget_collection), with a
>>    way (from a CMake flag) to build the pure-Qt widgets
> Why mixing the integration code and the widgets into one package?
Because they are NOT integration code. They are pure-C++, framework-free
widgets that can easily be reused outside of Rock. Especially those we
are talking about, since their only dependency is base/types.
>>  - a (as-yet-to-be-named) package with the packages that are dependent
>>    on the framework (e.g. task inspector)
> agreed -> they could go to rock-widget-collection
I would prefer rock_widgets and the other package common_widgets
>>
>> The problem where to put the code that binds the widgets to vizkit. I
>> would like to move the typelib-qt bridge to its own package in
>> tools/typelib_qt and the vizkit ruby code necessary to integrate the
>> widgets. I would personally be fine to have them in a bindings/rock
>> folder in common_widgets.
> I would put it into rock-widget-collection as well
And would then continue with the extremely annoying situation of having
the widget code and the vizkit-binding code in separate places.
bindings/ was created for the purpose of language bindings, I would
propose to extend it for that purpose as well and just place the
vizkit-binding code in the same package than the widgets.

-- 
Sylvain Joyeux (Dr.Ing.)
Senior Researcher

Space & Security Robotics
Underwater Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------