COOLFLuiD GUI current state and future
Quentin Gasper
First, let me wish a merry Christmas (with some late) and a happy new
year (with some advance) to all of you, your family, friends and pets
(if any).
I just finished with "purging out the server from Qt supremacy". As
from now the server will always be compiled if CF3_ENABLE_GUI is set
to true, whether Qt was found or not.
However, I haven't pulled to the main branch yet as the GUI is
currently completely unstable (it crashes whenever a signal needs some
options before being executed). After hours of investigations it
turned out that the problem was due to a conflict between Qt threads
and Boost threads (the latter are used internally by Boost.Asio to
handle asynchronous network operations). To be more specific, the
conflict is between Qt and Boost event loops. The issue "should" be
automatically (I know, there are no "should" in programming world ;))
fixed during the upcoming redesign of the GUI core API, which I hope
will be finished by the end of January (but it may be most likely mid-
February).
The current server is still multi-threaded. It has two threads: one
that listens to the network and one that listens to the MPI workers.
Besides that, it does one more task: remote file-system browsing from
the clients.
Next week I will start working on the new UI core API. I got a lot of
great new ideas. Here are some of them:
* use of the COOLFluiD log facility: using CFinfo in the GUI or one of
its plug-ins code prints to the log window
* management of preferences and settings (this might eventually lead
to a "Preferences" dialog on the GUI)
* provide a full developer manual in the Doxygen documentation
* a better interface for plug-ins
* provide services a developer would want to develop a user interface
(by the way, in the end, the GUI executable will become a plug-in too)
* support for custom component icons (more for the GUI part, see below
for details)
I'm aware that this process will ask a lot of work and, as I have no
experience in API design, I would like to present the progression of
work at (almost) all meetings so you can comment or criticize the
choices I make and maybe propose a better alternative.
Custom Component Icons:
I'm thinking about this for several months. The idea would be to let
developers set an icon to the component they just developed. This icon
would be shown in the tree view on the GUI. Icons are generally
managed as resource files (embedded inside the library/executable at
compile time).
For example, we would have a file '<path-to-icons>/
cf3.common.Group.png' or maybe '<path-to-icons>/cf3/common/Group.png'.
After adding the file, there are 2 ways:
- the developer edits an XML-formatted file to add the icon to the
project, and then recompiles the GUI
- we do a CMake script that looks for icons and builds the XML file;
the developer would have then to rerun CMake from the build directory
and recompile the GUI
Personally, I think the latter solution is better but I let you choose
since you will use this feature more than me ;)
Have nice end-year celebrations and see you in 2012 for new COOLFluiD
adventures :)
--
Quentin Gasper
============================================
Software Developer on COOLFluiD project
von Karman Institute for Fluid Dynamics - AR Department
www.vki.ac.be - https://github.com/coolfluid/coolfluid3
============================================
gque...@gmail.com
gas...@vki.ac.be
============================================
Tiago Quintino
On 30 Dec 2011, at 23:57, Quentin Gasper wrote:
> I just finished with "purging out the server from Qt supremacy". As
> from now the server will always be compiled if CF3_ENABLE_GUI is set
> to true, whether Qt was found or not.
Cool! IMHO, I think that server should now be always compiled.
The server in the long term should be independent of the GUI.
It could be there to answer connections from the python interface.
> However, I haven't pulled to the main branch yet as the GUI is
> currently completely unstable (it crashes whenever a signal needs some
> options before being executed). After hours of investigations it
> turned out that the problem was due to a conflict between Qt threads
> and Boost threads (the latter are used internally by Boost.Asio to
> handle asynchronous network operations). To be more specific, the
> conflict is between Qt and Boost event loops. The issue "should" be
> automatically (I know, there are no "should" in programming world ;))
> fixed during the upcoming redesign of the GUI core API, which I hope
> will be finished by the end of January (but it may be most likely mid-
> February).
That is very plan. But I think we should not be waiting for this to make the already delayed CF3 presentation.
> The current server is still multi-threaded. It has two threads: one
> that listens to the network and one that listens to the MPI workers.
> Besides that, it does one more task: remote file-system browsing from
> the clients.
Sounds good.
> Next week I will start working on the new UI core API. I got a lot of
> great new ideas. Here are some of them:
> * use of the COOLFluiD log facility: using CFinfo in the GUI or one of
> its plug-ins code prints to the log window
> * management of preferences and settings (this might eventually lead
> to a "Preferences" dialog on the GUI)
Yes, its is time the settings get grouped in one dialog.
> * provide a full developer manual in the Doxygen documentation
> * a better interface for plug-ins
What do you specifically have in mind?
> * provide services a developer would want to develop a user interface
> (by the way, in the end, the GUI executable will become a plug-in too)
Not so sure the GUI needs to be a plugin in itself, but I don't mind.
> * support for custom component icons (more for the GUI part, see below
> for details)
>
> I'm aware that this process will ask a lot of work and, as I have no
> experience in API design, I would like to present the progression of
> work at (almost) all meetings so you can comment or criticize the
> choices I make and maybe propose a better alternative.
I can also give you a help with the API design.
Email or skype.
> Custom Component Icons:
>
> I'm thinking about this for several months. The idea would be to let
> developers set an icon to the component they just developed. This icon
> would be shown in the tree view on the GUI. Icons are generally
> managed as resource files (embedded inside the library/executable at
> compile time).
>
> For example, we would have a file '<path-to-icons>/
> cf3.common.Group.png' or maybe '<path-to-icons>/cf3/common/Group.png'.
> After adding the file, there are 2 ways:
>
> - the developer edits an XML-formatted file to add the icon to the
> project, and then recompiles the GUI
> - we do a CMake script that looks for icons and builds the XML file;
> the developer would have then to rerun CMake from the build directory
> and recompile the GUI
Does this imply always a recompile? Is there no way to "register" the icon with the component?
> Personally, I think the latter solution is better but I let you choose
> since you will use this feature more than me ;)
If recompilation of the GUI is needed, then the latter solution is better,
but I rather have a solution where some code on each plugin is compiled and provides
a self-registring resource to the GUI. If that is possible.
Best,
Tiago Quintino
Quentin Gasper
On Dec 31, 8:31 am, Tiago Quintino <tlmquint...@gmail.com> wrote:
> Wishes of a Happy New Year to all of you!
>
> On 30 Dec 2011, at 23:57, Quentin Gasper wrote:
>
> > I just finished with "purging out the server from Qt supremacy". As
> > from now the server will always be compiled if CF3_ENABLE_GUI is set
> > to true, whether Qt was found or not.
>
> Cool! IMHO, I think that server should now be always compiled.
> The server in the long term should be independent of the GUI.
> It could be there to answer connections from the python interface.
> > However, I haven't pulled to the main branch yet as the GUI is
> > currently completely unstable (it crashes whenever a signal needs some
> > options before being executed). After hours of investigations it
> > turned out that the problem was due to a conflict between Qt threads
> > and Boost threads (the latter are used internally by Boost.Asio to
> > handle asynchronous network operations). To be more specific, the
> > conflict is between Qt and Boost event loops. The issue "should" be
> > automatically (I know, there are no "should" in programming world ;))
> > fixed during the upcoming redesign of the GUI core API, which I hope
> > will be finished by the end of January (but it may be most likely mid-
> > February).
>
> That is very plan. But I think we should not be waiting for this to make the already delayed CF3 presentation.
> > * provide a full developer manual in the Doxygen documentation
> > * a better interface for plug-ins
>
> What do you specifically have in mind?
CF ones.
Currently, the GUI plug-in interface allows plug-ins to create the
tabs and use them. Each plug-in creates a component in the client tree
when it is loaded. For now, this component only shows the user that
the plug-in is loaded. I think it's a good idea to add some features
like specific options or signals to this component. For instance, a
plug-in could register the components it can build. So the user can
right-click on the plug-in component and choose "Create New XXXXX".
The components a plug-in can build are already registered (i.e. the
GUI must be able to build a N3DView - provided by the ParaView plug-in
- when the server has a C3DView), I just want to extend the
possibilities.
I'm also thinking about a way to only load plug-ins the user wants
(like in Qt Creator). But I'm quite pessimistic about that feature.
> > I'm aware that this process will ask a lot of work and, as I have no
> > experience in API design, I would like to present the progression of
> > work at (almost) all meetings so you can comment or criticize the
> > choices I make and maybe propose a better alternative.
>
> I can also give you a help with the API design.
> Email or skype.
> > Custom Component Icons:
>
> > I'm thinking about this for several months. The idea would be to let
> > developers set an icon to the component they just developed. This icon
> > would be shown in the tree view on the GUI. Icons are generally
> > managed as resource files (embedded inside the library/executable at
> > compile time).
>
> > For example, we would have a file '<path-to-icons>/
> > cf3.common.Group.png' or maybe '<path-to-icons>/cf3/common/Group.png'.
> > After adding the file, there are 2 ways:
>
> > - the developer edits an XML-formatted file to add the icon to the
> > project, and then recompiles the GUI
> > - we do a CMake script that looks for icons and builds the XML file;
> > the developer would have then to rerun CMake from the build directory
> > and recompile the GUI
>
> Does this imply always a recompile? Is there no way to "register" the icon with the component?
compile time to handle this data. So each time an icon is added, the
class needs to regenerated, compiled and linked to the GUI.
Without recompiling the only solution I see is to have the icons
beside the executable, in a directory. From what I read on the
Internet, this is generally not recommended.
You can find an example of a such generated class in <path-to-cf-build-
dir>/cf3/ui/graphics/qrc_coolfluid-client.cxx. This one manages the
icons that you see in the log window.
> > Personally, I think the latter solution is better but I let you choose
> > since you will use this feature more than me ;)
>
> If recompilation of the GUI is needed, then the latter solution is better,
> but I rather have a solution where some code on each plugin is compiled and provides
> a self-registring resource to the GUI. If that is possible.
client side? Or icons would have to be sent by the server?
Resources are managed by Qt but...I know we can create an icon from a
char array (not sure how it is difficult, though). Then, yes, icons
can be registered inside the plug-in and read as binary data. But I
need to read more documentation to see how it is doable.
> Best,
>
> Tiago Quintino
Bart Janssens
> First, let me wish a merry Christmas (with some late) and a happy new
> year (with some advance) to all of you, your family, friends and pets
> (if any).
Happy new year!
> I just finished with "purging out the server from Qt supremacy". As
> from now the server will always be compiled if CF3_ENABLE_GUI is set
> to true, whether Qt was found or not.
Very nice progress!
> I'm aware that this process will ask a lot of work and, as I have no
> experience in API design, I would like to present the progression of
> work at (almost) all meetings so you can comment or criticize the
> choices I make and maybe propose a better alternative.
Of course! We could do a meeting this week already, not sure if
everyone is back from holiday yet?
> Custom Component Icons:
>
> I'm thinking about this for several months. The idea would be to let
> developers set an icon to the component they just developed. This icon
> would be shown in the tree view on the GUI. Icons are generally
> managed as resource files (embedded inside the library/executable at
> compile time).
I would prefer to keep the icons separate, as SVG or PNG, unless there
are major objections against this? We could have some sort of "share"
directory, where we put icons. Naming could follow the namespace
convention, if the icon is found it is used, if not the default is
used.
Cheers,
--
Bart
Willem Deconinck
# copy files to resources dir in build tree
foreach( rfile ${resources_files} )
add_custom_command( OUTPUT ${rfile}
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CMAKE_CURRENT_SOURCE_DIR}/${rfile} ${CF3_RESOURCES_BINARY_DIR} )
#COMMENT "Copying file ${rfile} to ${CF3_RESOURCES_BINARY_DIR}")
endforeach()
add_custom_target( copy-resources ALL DEPENDS ${resources_files} )
Willem Deconinck
Bart Janssens
<ir.willem...@gmail.com> wrote:
> Could we arrange a meeting monday (or later)? I am quite busy this week.
Yes, I'm free on Monday, Tuesday and Friday!
> About the icons, I really think it is a great idea to allow custom icons.
> I can already imagine people "modding" coolfluid 3 with their own themes
> haha.
> How I see it, is that we already HAVE, a folder called resources, where now
> there are stored some meshes.
> I also don't want to embed icon registration in any of the cf3 common
> codes.
> I propose, somewhat similar to Bart, to put all components in the resources
> folder, following the component's type-name (problem with template-argument
> components such as common::Map<T1,T2> …?).
> plugins can provide icons, and write CMake code to copy the icons in the
> resources folder.
Yes, I think having som sort of standardized location for these items
is the way to go. We could also look for inspiration in other Qt tools
(i.e. paraview?), see how they handle this sort of thing.
Cheers,
--
Bart
Willem Deconinck
So with no further objections, monday (tomorrow), is a good day to meet for me.
At 10am as usual.
Objections?
-Willem
Bart Janssens
<ir.willem...@gmail.com> wrote:
> Dear cf3-ers,
>
> So with no further objections, monday (tomorrow), is a good day to meet for me.
> At 10am as usual.
No objections for me. Tamás, OK for the VKI?
Cheers,
--
Bart
Bart Janssens
<bart.j...@lid.kviv.be> wrote:
> On Sun, Jan 15, 2012 at 4:18 PM, Willem Deconinck
> <ir.willem...@gmail.com> wrote:
>> Dear cf3-ers,
>>
>> So with no further objections, monday (tomorrow), is a good day to meet for me.
>> At 10am as usual.
>
OK, since this was probably too late for anyone to see it: How about
we reschedule to Tuesday? I'd prefer to go to the RMA tomorrow anyway,
since I wasn't there Friday either.
Cheers,
--
Bart
Willem Deconinck
Tuesday is good for me as well.
-Willem
Martin Vymazal
Tamás Bányai
Th
Quoting Martin Vymazal <martin....@gmail.com>:
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Tamás Bányai
Th
Quoting Willem Deconinck <ir.willem...@gmail.com>:
> Dear cf3-ers,
>
> So with no further objections, monday (tomorrow), is a good day to
> meet for me.
> At 10am as usual.
>
> Objections?
>
> -Willem
>
> On 10 Jan 2012, at 20:51, Bart Janssens wrote:
>
>> On Tue, Jan 10, 2012 at 6:25 PM, Willem Deconinck
>> <ir.willem...@gmail.com> wrote:
>>> Could we arrange a meeting monday (or later)? I am quite busy this week.
>>
>> Yes, I'm free on Monday, Tuesday and Friday!
>>
>>> About the icons, I really think it is a great idea to allow custom icons.
>>> I can already imagine people "modding" coolfluid 3 with their own themes
>>> haha.
>>> How I see it, is that we already HAVE, a folder called resources, where now
>>> there are stored some meshes.
>>> I also don't want to embed icon registration in any of the cf3 common
>>> codes.
>>> I propose, somewhat similar to Bart, to put all components in the resources
>>> folder, following the component's type-name (problem with template-argument
>>> components such as common::Map<T1,T2> ...?).
>>> plugins can provide icons, and write CMake code to copy the icons in the
>>> resources folder.
>>
>> Yes, I think having som sort of standardized location for these items
>> is the way to go. We could also look for inspiration in other Qt tools
>> (i.e. paraview?), see how they handle this sort of thing.
>>
>> Cheers,
>>
>> --
>> Bart
>
>
----------------------------------------------------------------