[Rock-dev] splitting rock-widget-collection

[Allan E. Conquest]

On 13.05.2013 11:06, 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.
>
>> 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
I don't understand the necessity of making the build of the pure Qt 
widgets optional. They are as essential to Rock as any Rock-'dependent' 
widget. The best example is ImageView. It is basically a pure Qt widget 
if we transform the base::frame::Frame to QImage beforehand and change 
the setFrame interface accordingly.
> Why mixing the integration code and the widgets into one package?
> Having one repro which hosts pure qt widgets and a second one
> integrating them into rock is the better solution for me.
+1

It would also be more convenient for the community to access the the 
common widgets separately from Gitorious.
>
>>   - 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
>>   - vizkit3d, the RTT-independent 3D view based on OSG
>>   - vizkit, the framework dependent ruby library.
> agreed
>> 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
>
> Alex
>
Maybe this is the right time to discuss another issue:

We are currently implementing some widgets in C++ and some in Ruby. I 
believe there is no way to integrate Qt/Ruby widgets in QtDesigner (?). 
If this is true, we should discuss about a policy when to use which 
language.

Regards,

Allan