Qtvcp Development Discussions

I was thinking it might be nice to have a easier way to copy the qtvcp screen code files over for some one to start modifying a screen.

I was thinking a command such as:
qtvcp copy_screen

That pops up a dialog to allow searching for the screen/panel code folder and assist the coping of selected files into a folder.

Though maybe I shoul'd make it to easy - I'm still deciding how the folders should be set up.

Right now I favour images in one separate folder, which does make it awkward to move screen/ui code.

Ideas?
Chris

If someone could make this sticky for me... Thanks

cmorley wrote:

I was thinking it might be nice to have a easier way to copy the qtvcp screen code files over for some one to start modifying a screen.

I was thinking a command such as:
qtvcp copy_screen

That pops up a dialog to allow searching for the screen/panel code folder and assist the coping of selected files into a folder.

Though maybe I shoul'd make it to easy - I'm still deciding how the folders should be set up.

Right now I favour images in one separate folder, which does make it awkward to move screen/ui code.

I think that is a good idea. So long as there is naming and location consistency it shouldn't be too difficult.

Are you referring to the handler file when you talk about screen copying or more of a qtvcp ui screen copying? because either would be awesome.

Is this thread for specifically those 2 topics or qtvcp development in general? I ask because a lot of commits go up for qtvcp and it is sometimes hard to find reference to what or why something changed . if the answer is the latter, then i have a question regarding a recent commit
github.com/LinuxCNC/linuxcnc/commit/8acb...deafe67d7ad17b355c44
github.com/LinuxCNC/linuxcnc/commit/94a7...89f9af9c4c29a0d6db1a
still grasping on how it works, but since its function is to hide unwanted lines until something, for example, meaning only the g1 lines drawn after the colour change call will show up red, and all the g1 moves prior to the colour change will remain blue?
Does that mean we can change preview colours through the program while running? or only before auto? I only ask because it could be useful for things such as like changing colour backplot based on tool/tool change (t1=red, t2=blue) , or perhaps colour changes based on halpin output ranges? for example backplot lines change colour based off spindle load(green=0-10%load ,red 80-89%) or temp reading from something (blue=30-39degrees red=50-59, orange=60-69,etc) ?

phillc54 wrote:

I think that is a good idea. So long as there is naming and location consistency it shouldn't be too difficult.

I'll see what I come up with and then I'll ask opinions on it then. Thanks

cakeslob wrote:

still grasping on how it works, but since its function is to hide unwanted lines until something, for example, meaning only the g1 lines drawn after the colour change call will show up red, and all the g1 moves prior to the colour change will remain blue?
Does that mean we can change preview colours through the program while running?

In the handler file (gcodegraphics needs to be the right widget name)
key words can be jog=None,traverse=None,feed=None,
arc=None,toolchange=None,probe=None

color = (red, green, blue, alpha)
each are 0-255

I have not tried to change color as the plotter is running - but it should work.

There is any way we can use QTvcp with C++ using qtcreator, I know the adventages of python however C++ has a better performance at run time since it is compiled not interpreted.

I'm not sure i understand your question - do you want qtvcp rewritten in c++ ?
if so my answer is not by me and I would not support the idea of it.
Performance is not the biggest priority of screens.

In what way is python's performance not up to the task?
linuxcnc has no screens that are written completely in C or C++ and I don't hear constant complaints of performance - only openGL problems.

That being said - it should be completely possible to write specific _widgets_ in C++ and have them incorporated in QtVCP - just as one can right now use any QT widget that has a qtdesigner plugin.

The biggest problem with C++ code is you automatically create a high bar for people to maintain and modify them. We already have a lack of developers willing/able to work in linuxcnc.

Chris

GMoccapy is a perfect example.
Norbert wanted to build a screen similar to Mocca (written in pascal! if I recall correct).
At the time I was creating Gscreen infrastructure.
Between the two of us we created enough widgets and infrastructure to create Gscreen/GMoccapy and allow ofhers to create/modify screens.

If C C++ was our only option neither would have been written and our only option would be AXIS with pyvcp panels.

understood