building custom Gladevcp Widgets for linuxcnc

I was talking python bindings.
Python is easier for noobies (and me) to work with. and seems fast enough.

I just am fooling with it at the moment, so am not up to speed with QT's way of doing things.
most of the examples on the web use pyuic to make the XML into a module.

I don't like this step for our uses so am doing it directly - just like gladeVCP.

Are you going to publish your work? was it QT3 or QT4?

John

I think we should unhide the developers manual and start adding to it.
making GLADE widgets is definitely developer work.
The integrators manual is going to be huge if we add everything to it.
and if its huge people are less likely to read it.

having a developers manual would also promote documentation of best practices, objectives, and lower the guru bar
I think anyways...

Chris M

Why is it that we can't have HTML docs in the cnc menu?

I am not a big fan of the PDF's preferring the HTML's links too.
i assume the PDFs are easier when printing.

Even using HTMl docs I personally prefer the subjects broken down in say three manuals.

User
integrator
developer

eg.
I see the user manual as lightly touching on say HAL ideas
the integrator deeply covering using HAL, touching on creating HAL
the developers manual deeply into creating/interfacing to HAL

But that is just me.
Don't get me wrong the manuals are great as they are !
just as we document more and more they get bigger and harder to reference.
We might want to consider a plan for linuxcnc3 docs rather then again reorganizing the linuxcnc2 docs.
Anyways I'm off topic - It's small I'll put it anywhere you think it should go.

Chris M

cmorley wrote:

I was talking python bindings.
Python is easier for noobies (and me) to work with. and seems fast enough.

I just am fooling with it at the moment, so am not up to speed with QT's way of doing things.
most of the examples on the web use pyuic to make the XML into a module.

I don't like this step for our uses so am doing it directly - just like gladeVCP.

Are you going to publish your work? was it QT3 or QT4?

I am using Qt4, now that I have got my head around the changes from 3, I prefer it.

The uic conversion of .ui to a header file with the graphical setup for the program, is a very powerful tool when you get used to it.
In C++ it means you can write a class which inherits the class created by uic and create the entire graphic interface just by calling setup_UI()
Don't know if it is quite the same with the python bindings.

It allows you to program the GUI completely graphically in Designer, make changes and it is compiled on the fly without affecting your code.
(assuming you use qmake, .pro files etc)

I have lots of changes and polishing to do, as I gradually test all the library functions, but in due course I may well publish it.

Presently I am patching Axis to read a [QTVCP] section in the .ini file and based upon the entries spawn the qtvcp binary and then parse a qtvcp.hal file to make all the necessary pins connections.

You may be able to help.
I am having trouble getting the .ini file name from within Axis so that I can spawn the qtvcp binary with that as an argument
sys.argv[2] should contain it, but it is returning rubbish when I use it. I think inifile is actually a class rather than a string.
The linuxcnc script create an env variable $INIFILE with that name but I can't seem to grab that either.
Any ideas ?
My python knowledge is only in so far as it resembles C/C++, so it is slow going googling every time I get stuck

regards

You may be able to help.
I am having trouble getting the .ini file name from within Axis so that I can spawn the qtvcp binary with that as an argument
sys.argv[2] should contain it, but it is returning rubbish when I use it. I think inifile is actually a class rather than a string.

Cancel the above - found the problem. Some screwy thing with python where you allocate a global string but unless you specify global stringname inside local functions, they just create another string of the same name which of course does not have what you expected in it

ArcEye wrote:

I am using Qt4, now that I have got my head around the changes from 3, I prefer it.

The uic conversion of .ui to a header file with the graphical setup for the program, is a very powerful tool when you get used to it.
In C++ it means you can write a class which inherits the class created by uic and create the entire graphic interface just by calling setup_UI()
Don't know if it is quite the same with the python bindings.

It allows you to program the GUI completely graphically in Designer, make changes and it is compiled on the fly without affecting your code.
(assuming you use qmake, .pro files etc)

For a user friendly qtVCP there cannot be a compiling step.
There cannot be a two step process to make the Panel.
One should make the panel in designer then load it inside of HAL with the loadusr command.
Which is completely doable - I have a working basic example in another thread.

Now if you are talking of building a full GUI screen for linuxcnc then I don'tt see the compiling step as such a barrier.
Though not having to compile is oh-so-nice. I have built gscreen with gladevcp widgets - no compiling.
Well no compiling unless you edit the basic gladevcp widget - which i have done but normally one wouldn't need to.

Are you embedding the QT panel inside AXIS? can you get the panel to match the basic look of AXIS (themes)?
Do you have a screen shot?

Chris M

Hi Chris

For a user friendly qtVCP there cannot be a compiling step.

Depends whether you are bothered about following the pre-existing work flow processes or doing things differently.
To a large extent the perceived lack of compiling with python is erroneous, its just that the compilation to machine code takes place on the fly at run time.

One should make the panel in designer then load it inside of HAL with the loadusr command.

My panels don't need to use loadusr, they have access to the running Linuxcnc instance and all the HAL libraries.
They just need to be named in the .ini file and the patch to Axis spawns them like a normal binary
They create themselves, get their comp_id from the running instance, create and populate their pins. They could do the linkages to external pins too, but it is probably more easily maintained
to treat them as components and do these linkages through a .hal file.

Now if you are talking of building a full GUI screen for linuxcnc then I don't see the compiling step as such a barrier.

That wasn't my intention, but I can see that eventually I might go that way, it would make everything far easier.
My biggest problems come from trying to interact with Axis.

Are you embedding the QT panel inside AXIS? can you get the panel to match the basic look of AXIS (themes)?

At present I am creating a separate panel, embedding / docking with Axis is the major headache, whereas it would be simple if Axis were a Qt app.
No I most definitely not trying to match the look of the GTK widgets, I can't stand them!

Do you have a screen shot?

A very simple one of a test panel which mimics the toolchanger pyVCP that John put out at
www.linuxcnc.org/index.php/english/forum...changer?limitstart=0
Seemed a good enough place to start.



regards

By compiling step I meant a two step process to get a panel built.
In a pyVCP or gladeVCP the user builds the UI file then loads the panel in linuxcnc.
How python actually does it doesn't matter. the point is the user doesn't have to do anything else beside make it and load it.

I'm not sure I see the advantage of loading them through AXIS. It is limiting- not everyone uses AXIS and I doubt the maintainers of AXIS will be keen on patching AXIS this way - if you are interested in adding your work to linuxcnc in the future that is.
GladeVCP and pyVCP create their own pins and components - loadusr simple calls the programs that do this.
You can add loadusr python something and it will run a python program - you probably know this.
You can do the opposite too. you could load gladeVCP panels outside of the linuxcnc script.

Actually AXIS uses Tk widget set. not GTK. What I meant was can you theme the QT widgets to look more natural in a TK or GTK environment?
GladeVCP widgets can be themed - some of the themes look natural in AXIS - different but natural.

Why would you not use the default mechanism to embed windows into AXIS?

I don't mean to sound critical - I'm just curious.

Chris M