GScreen and some understanding gap of hal-widgets

Sorry i'm tired...

No problem Chris - I found that command by looking at the source of GScreen.
Thanks!

Hi,

I'd like to create actions and widgets like is done in gladevcp.
I added a directory to python path as well as to glade catalog path and created a file with a first action.
But - as expected - nothing happened.
So I guess there's much more I missed.

When I look at hal_action.py the actions are named EMC_<whatever> but designer knows them as vcp_<whatever> ...
... but in the glade file, action type is EMC_<whatever> and the default name is vcp_<whatever>.

So who brings in the vcp_ naming and handling for the designer?
And how can I bring my classes into play?

maybe this helps:
wiki.linuxcnc.org/cgi-bin/wiki.pl?GladeVCP_Custom_Widgets

Chris M

Hi Chris,

I already skimmed that page, but have overseen the most important part.
Thanks for the link!

Currently I'm diving into Gscreen ...
Don't know, whether I got things right: GScreens submodules (like keybindings or mdi) are duplicated at location lib/python/gscreen and src/emc/usr_intf/gscreen - but as the later is not part of python path, those files are not used, as there are no *pyc files in that directory.
Right?
lib/python/gscreen contains *pyc files, so those files seem to get used.
But I did not find a pyc-file for gscreen.

My ini-file has a Display line like: gscreen -d -c <myUI>
so I guess, that gscreen is used.

Is there another gscreen instance, that could process glade files, without using gscreen.py?
Terminal messages look like originated from gscreen.py, but why isn't there a pyc file?

src/emc/usr_intf/gscreen - these files are copied to lib/python/gscreen - probably from tradition of using compiled languages more then any other reason

gscreen.py is copied as gscreen into bin

the submake file and Make file lay this out if you can 'read' make files - they hurt my head



What does you rnew action do?

Chris M

src/emc/usr_intf/gscreen - these files are copied to lib/python/gscreen - probably from tradition of using compiled languages more then any other reason

gscreen.py is copied as gscreen into bin

Thank you for pointing this out.
There is so much redundant stuff, so sometimes i think, that obfuscating was primary goal on development
.

What does you rnew action do?

Nothing that your gscreen does not already do.
I just think in more object orientated way and for so put information and ability to the place it belongs to.
GScreen looks like a real fat class, that might be ok for the handling of the gscreen.glade files, but does not look appropriate as a base class to support custom screens ...
But may be I'm wrong. Stil learning, searching, trying to understand, searching again ...

And I'm not sure, whether creating actions would be appropriate or better create widgets ...
For example: I'd like the togglebutton be able to change the button images on signal change without the need of handler interaction ...
You know, I already worked out a notebook fake, that does not respond to mouse actions in edit mode ...
So I think about nice looking usability ...

cheers Reinhard

Gscreen was built with out a plan other then to build a configurable screen.
I am also not a programmer by trade - so learn better practices on the way.
Originally the idea was that gscreen would have all the basic functions you would need in it's class. I later realized this to be too restricting and as you noted bloated.

Norbert of Gmoccapy fame (Gmoccapy was a gscreen skin originally) and I worked on many widgets to make screen building more plug and play, I'd hoped others would build more widgets along the way. For instance I intended to build an multi-image display widget, HAL pin controlled, I just never needed it so ther things took priority.

Being able to code directly is actually much easier in the short term - widgets take planning to be general enough.

I feel qtvcp is an improvement in the plan part.
I urge you, if you wish to put much effort into widget building to switch to qtvcp.
Gladevcp's development future is a question mark.

Chris M

I urge you, if you wish to put much effort into widget building to switch to qtvcp.
Gladevcp's development future is a question mark.

Well, anytime I try to use Qt, I vomit the F-word - you know what I mean.
I never got something useful into play with Qt - so I stay at things that work.
Currently I don't miss anything, that Qt might offer and glade does not.
May be, that may change over time.
But I don't have the time to waste in getting Qt to work.
I think, if its not possible, to get a working Qt environment on a fresh VB-installation, something big must be wrong and its not my system being wrong.
Actually I don't feel like wasting time in learning gscreen, python and linuxcnc ...

Reinhard wrote:

I think, if its not possible, to get a working Qt environment on a fresh VB-installation, something big must be wrong and its not my system being wrong.

It's actually most likely something small - the small problems are hard to find not big ones.

Reinhard wrote:

Actually I don't feel like wasting time in learning gscreen, python and linuxcnc ...

Then I don't understand why you are doing it. Linuxcnc trades money for time invested.
Building screens requires a large investment. Building widgets etc requires even more.

I mean not to discourage you understand, it's just a confusing position to me.

Chris M

Chris M

If you have an idea, let me know. I'm willing to try again an installation - if there's a chance to success