QT C++ graphics display WIDGET

Hi Grotius,

I very estimate your work, but I'm no friend of collapsed strings to paint over whatever.
I'm a friend of strict decoupling model from view.

I just published my wip so you can look what I mean.
DxfView is derived from your simple_cam and extended to show 3D dxf files as written by freecad.
QtUi is the source of above screenshots. A combined widget to handle all tasks around dro
Recently I have started to work out a gcode viewer/editor ...

I added some of your grafic widget properties to DxfView. When you load a 3D dxf file, you can play with menu entries to see live changes.
I did quite a lot of changes to the dxf layers and to your opencascade widget.
Hope you find it useful.

Hi Reinhard,

Nice work !

* Hope you find it useful.
Yes, sure. It's alway's nice to see contributions that can help you go on. And to learn from different coding style's.
I see your github channel has a clean overview, also your c++ code is clean. Generally qt libs are used.

* but I'm no friend of collapsed strings to paint over whatever.
Yes, that's something to discuss.
For today i will let the dro text as it is. The basic code (proof of concept) for showing dro's works.

The widget overlay is done outside of qt. Qt cannot do the transparant overlay properly on a opencascade widget.
There was a discussion somewhere that also mentioned that. It can be done by a complex solution, but i stay away from that.
The dro text is now done by opencascade itself trough a simple "textlabel" way and showing it's position as the trihedron cubic does.

Now i will try to include a nml header file to get the dro values from lcnc.
But for a universal widget, we not alway's read the values this way. Hal-core will read the dro's trough hal.










 

The dro text is now done by opencascade itself trough a simple "textlabel" way and showing it's position as the trihedron cubic does.

Yes, I realized it.
But instead of collapsing all dros into a single string, it could probably be possible, to simulate different labels. If you look at axis, there are plenty of dros and I'm sure, not every user wants all that dros.
So to get it configurable, the best way *imho* is to treat each value as different element. Such element will have a position, a font and a forground and background color.

Painting could stil be performed by opencascade. Just have some elements, that listen to update events.

Hi Reinhard,

Yes we will do it that way you suggested.

Currenty implemented as QProperty:
OpencascadeWidget->setProperty("property_background_color", 0);
OpencascadeWidget->setProperty("property_show_orthographic_or_perspective", 1);
OpencascadeWidget->setProperty("property_view_front", 1);
OpencascadeWidget->setProperty("property_view_back", 1);
OpencascadeWidget->setProperty("property_view_top", 1);
OpencascadeWidget->setProperty("property_view_bottom", 1);
OpencascadeWidget->setProperty("property_view_left", 1);
OpencascadeWidget->setProperty("property_view_right", 1);
OpencascadeWidget->setProperty("property_view_wireframe_or_shaded", 1);
OpencascadeWidget->setProperty("property_zoom_all", 1);
OpencascadeWidget->setProperty("property_erase_all", 0);
OpencascadeWidget->setProperty("property_hide_or_show_triedron", 0);
OpencascadeWidget->setProperty("property_show_interactive_3d_box", 1);

To be reviewed:
OpencascadeWidget->setProperty("property_show_dro", dro_result);

Yes, I saw that property stuff.

What you think: if you spend more time in opencascade research, I could do the nml task for you.

Hi Gentleman,

I added a dro example to the widget, please look and comment :
user-images.githubusercontent.com/448801...373-b3bdf14df8e4.mp4

To discus, the dro properties can be for example :

• textheight
• transparancy
• color
• contains just one QString for entire dro result
• dro position x,y
• not highlighted by mouse visit
  
  etc, etc.
  
  I only need to know more about the dro wishlist, thanks.
  
  

That looks very good. DROs Numbers are usually right side justified with fixed length fractional part.
Displaying feedrate is usual, spindle speed would probably be good to, but these need to be optional.
limit-switch-tripped and homed icons that show up beside the axis when appropriate should be considered in the future.
Also the DRO must be flexible enough to show joint position (before homing) on machines that have more joints then axes.
Whether that means you having two overlays that can be exclusively shown would be better or one that can can be configured on the fly, I don't know.
I wonder if it is possible to overlay a separate DRO widget on top of the graphics display? That would be very flexible but I'm not sure if getting it to work with resizing would be difficult.

Is there instructions how to compile your widget? I'm not very up on C++ programming, but given rough instruction I'll do my best.

Thanks for working on this!
Chris

Hi Reinhard,

Yes, good proposal. Can you integrate a option for the nml?

If the universal widget is integrated for example in hal-core it does not have the nml header files and will only interact trough
Qproperties and or hal. Is it then possible to include something like :

ifdef
NoNML.h
// Do not load any nml headers, else load nml headers.
endif

Thanks.

Hi Chris,

We will include :
- feedrate [F]
- optional : spindle speed
- limit-switch-tripped
- homed icons

* two overlays that can be exclusively shown would be better.
Yes, we do it this way.

* I wonder if it is possible to overlay a separate DRO widget on top of the graphics display? That would be very flexible but I'm * * not sure if getting it to work with resizing would be difficult.
Just created a second opencascade interactive context. Each context can show it's own stuff on the screen. Tested ok.
For example, the m_context_dro holds all the dro info. This context is not hightlighted anymore by mouse hover.
- Handle(AIS_InteractiveContext) m_context, m_context_dro;

* Is there instructions how to compile your widget? I'm not very up on C++ programming, but given rough instruction I'll do my
* best.
If you want to test it on the c++ side, you could do install qt and opencascade:
- github.com/grotius-cnc/Linux-Pro/release...1.0.0/qt-creator.deb
- github.com/grotius-cnc/Linux-Pro/release....0.0/opencascade.deb

If you want to integrate it with Python:
We have some work todo before giving the instructions. Now the widget is acting like a program with a mainwindow for runtests.
When we are ready, we will transform the project into a shared .so library including the header file and a Qproperty instruction list.
Will this be good enough for using with Python? I have no clue..


Just got the label background color working. Now steaming up to "limit switch tripped" and "home" icons for each axis.
 



 

Hi,

I played a bit with Qt and I just succeeded in creating working Qt-overlays:
 
That app is designed for dockables around a center widget (where graphic widget would be added). Currently the center widget acts like a stack of displays, which can be switched by applications main menu.
The dockable dro already can change number of shown axis by axismask and left dro column can switch between absolute and relative.
The overlay is just a simple test, but the features from dockable could be implemented for overlay too.

If you like to play with the sources: github.com/DjangoReinhard/QtUi
 

Hi Reinhard,

Nice work !
Yust checked your app. It run's nice !
Have a look at the dxf viewer, pull request.

You gcode textbox looks very nice with this colors.

The widget overlay will indeed work nice between qt widgets.
For a combination with opencascade it's another story (so far as i can see ), transparancy will be lost.
Yesterday i investegated the source of Mayo, wich used a few on schreen buttons. But there also no transparancy above
the opencascade widget over there.

It took me whole day to solve a tiny problem, loading textures into the opencascade screen. In the end the problem
occured at compile stage of opencascade source code.
Here's the solution : github.com/tpaviot/oce/issues/744#issuecomment-908528485
This solution has to be merged into the opencascade.deb soon.

Video showing textures (pictures) :
user-images.githubusercontent.com/448801...f8e-fe4ec528bc4e.mp4

We needed this texture option to preview the "home" and "limit switch" triggers as Chris mentioned.
Now this is solved.

 

Hi Reinhard,

I will try to create a type dro like this :
 

To this dro we can apply the properties :
- icon limit switch triggered
- icon homed
- transparancy level (0 to 1)
- background color (enum color) or background picture (file.png)
- textcolor (enum color)
- text font ("arial" etc)
- screen position (x,y).
- 7 or more configurable input fields ( as shown in picture )
- Create a vector (=user defined ammount) of dro's[x] when opencascade widget is loading.

To the main widget we add :
- set background image (file.png) or set background color (enum)

I will give it a go. Maybe the result is cool !