Plugin with ui_resources in environment without Qt

Development
1

Hi all,

I’m currently trying to build a plugin that has its own ui_resources. So i’am declaring it with the UI_RESOURCES keyword of the paraview_add_plugin function.

I need to compile this plugin in an environment where ParaView is built with Qt support (in this case the compilation succeed) but also in an environment where ParaView has no Qt support and in this case i got configuration failure with the Cannot find Qt message.

A workaround is to use the UI_RESOURCES only if the variable PARAVIEW_USE_QT is true.
Is it the right way to do?

thanks in advance

2

Yes.

3

Thanks @ben.boeckel for your quick answer.

I was wondering why in the ParaViewPlugin.cmake file, the link to Qt, when dealing with such ui_resources, is not conditionally made according to the value of ${PARAVIEW_USE_QT} ?

According to you, does it worth a MR in ParaView ?

Thanks

4

I’m not sure what you mean? Are you saying that UI_RESOURCES should add some Qt library to _paraview_add_plugin_required_libraries? I guess it’s needed for the Q_ macro that is injected.

5

No that’s not what i meant. Sorry to have been unclear.

I was just wondering why i have to do this “manually” in my plugin and why the lines in ParaViewPlugin.cmake dealing with ui_resources are not wrapped in a if (${PARAVIEW_USE_QT})/endif(). It is probably a very naive question.

6

Oh, I see. A plugin could be built for an application that is not ParaView that brings its own Qt layer. I suppose it’s probably a long shot, but if we have a better signal (say, if (TARGET ParaView::pqCore) perhaps?), we can no-op the Qt bits based on that.

Looking, we do assume that exists, so it would probably be one way.

However…silently turning off things based on environmental things is also something I’ve tried to avoid in VTK and ParaView. Maybe an explicit DISABLE_QT_IF_NOT_PRESENT flag would suffice?

7

@ben.boeckel thanks for your answer.

If i understand you well, you suggest to introduce a new option in ParaView’s build system : DISABLE_QT_IF_NOT_PRESENT.
If this option is on and PARAVIEW_USE_QT is also true then we can no-op the Qt bits?
I’am i right?
If so i’ll be glad to make a MR.

8

No, there would be a new argument to paraview_add_plugin that would no-op any Qt bits if it is present and the requisite ParaView target(s) are not available.

9

All right. I see. It’s very clear thanks.

I’ll try to do a MR ASAP.
Thanks

10

I just saw that the lines below have been recently added to the paraview_add_plugin function.

  if (_paraview_add_plugin_UI_INTERFACES OR _paraview_add_plugin_UI_FILES OR _paraview_add_plugin_UI_RESOURCES)
    if (NOT PARAVIEW_USE_QT)
      message(FATAL_ERROR "UI_INTERFACES, UI_FILES and UI_RESOURCES require ParaView to be built with Qt enabled.")
    endif()
  endif()

As the warning is very explicit i suppose there is not anymore the need for the DISABLE_QT_IF_NOT_PRESENT option. What do you think about it @ben.boeckel ?

11

Indeed, trying to add ui_resources when building against a non-qt build of paraview now fails at cmake configuration time.

If the plugin still need the resources, they should be handled “manually” in the CMakeLists, as shown in this (new) example https://gitlab.kitware.com/paraview/paraview/-/tree/master/Examples/Plugins/ServerSideQt

12

What is this option? I don’t see it in the source tree.

13

@ben.boeckel this option was a suggestion you made a few lines above.

14

Ah, I see. It’s something we can add if plugins are using Qt independently and there’s no ParaView/Qt related logic with the option that “makes sense” to just turn off.