1. User Interfaces
  3. Other User Interfaces
  5. GScreen and some understanding gap of hal-widgets

GScreen and some understanding gap of hal-widgets

More
27 Jun 2019 07:02 #137969 by cmorley
Replied by cmorley on topic GScreen and some understanding gap of hal-widgets
I don't - when I tried an installed version it works fine for me.
But I don't use a VB, I use an english system, my system did have a compiled version on too... etc any of these things could be a problem.

I prefer and am most familiar with, a compiled version of course.

I do have a little time so might try a fresh install, but until i can get it to fail ....

But if you just want a custom screen for yourself - you have invested in Gscreen so why not continue.
I just wouln't bother with trying to build custom widgets/actions - just use the available widgets and program the rest in the handler file.

Just long term GTK2 seems not to be included in the newest Debian versions - though other distributions I bet will still include them. Not a problem unless you insist on the newest version of distributions
It's a transitional time right now for widget toolkits and python.

sleep time...

Chris M

Please Log in or Create an account to join the conversation.

More
27 Jun 2019 07:53 #137975 by Reinhard
Replied by Reinhard on topic GScreen and some understanding gap of hal-widgets

Just long term GTK2 seems not to be included in the newest Debian versions

Hm, what's that statement based on?

When I look a debians package information of gtk-2, it shows this:
Quellcode-Paket gtk+2.0

    jessie (libs): 2.24.25-3+deb8u2
    Binär-Pakete: gir1.2-gtk-2.0, gtk2-engines-pixbuf, gtk2.0-examples, libgail-common, libgail-dbg, libgail-dev, libgail-doc, libgail18, libgtk2.0-0, libgtk2.0-0-dbg, libgtk2.0-0-udeb, libgtk2.0-bin, libgtk2.0-common, libgtk2.0-dev, libgtk2.0-doc
    stretch (libs): 2.24.31-2
    Binär-Pakete: gir1.2-gtk-2.0, gtk2-engines-pixbuf, gtk2.0-examples, libgail-common, libgail-dbg, libgail-dev, libgail-doc, libgail18, libgail18-udeb, libgtk2.0-0, libgtk2.0-0-dbg, libgtk2.0-0-udeb, libgtk2.0-bin, libgtk2.0-common, libgtk2.0-dev, libgtk2.0-doc
    buster (libs): 2.24.32-3
.
. 
.
    sid (libs): 2.24.32-3
    Binär-Pakete: gir1.2-gtk-2.0, gtk2-engines-pixbuf, gtk2.0-examples, libgail-common, libgail-dev, libgail-doc, libgail18, libgail18-udeb, libgtk2.0-0, libgtk2.0-0-udeb, libgtk2.0-bin, libgtk2.0-common, libgtk2.0-dev, libgtk2.0-doc
which means, that gtk2 packages are stil part of the most recent debian version

So what am I missing?

Please Log in or Create an account to join the conversation.

More
27 Jun 2019 19:17 #138020 by cmorley
Replied by cmorley on topic GScreen and some understanding gap of hal-widgets
based on this exchange:

tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%...evel/2019-06-13.html

but you are right, in there they do mention it is still available in buster.
GLADE editor is not but it hasn't been included for a long while. I think we forward port a ubuntu package for it.

Chris M

Please Log in or Create an account to join the conversation.

More
28 Jun 2019 03:08 - 28 Jun 2019 03:10 #138081 by Reinhard
Replied by Reinhard on topic GScreen and some understanding gap of hal-widgets

GLADE editor is not but it hasn't been included for a long while.

debian has glade editor included - of cause!
Current stable, as well as SID.

The outdated version of glade-editor, that's required for linuxcnc isn't part of debian.
I guess, it's not part of any linux.
But compiling it from a download package is not a challenge. One has to keep in mind, that the executable has a different name (the outdated is named glade-3 versus glade, which is the current release).

The only downside comes from linuxcnc again: working on custom screenset works in rip-environment only. No description leads to a working environment without rip installation.

Debians preferred window-manager (gnome) is based on gtk, so I can't believe, that debian will give up gtk.
Last edit: 28 Jun 2019 03:10 by Reinhard.

Please Log in or Create an account to join the conversation.

More
28 Jun 2019 12:35 - 28 Jun 2019 12:36 #138113 by Reinhard
Replied by Reinhard on topic GScreen learning: what happens at widget.connect() ?
Hi,

I successfully created a glade with handler that connects signal-callbacks without the use of gscreen.
Then I grabbed the sources of pygtk to see, what happens at widget.connect() - but I had no success.
Most of pygtk is wrapper-description - does not really help understand.

I guess that event is just a function call and a handler is a function callback. So connect needs to enter the callback into the function call.

Why I ask? - I think, the widget itself has some actions that need to be performed on certain event and the callback-provider does not need to know about the internal actions.
So when I want to extend the internal actions without disrupting the event-mechanism, where should I place my code (I don't want it to put into the handler. Should be part of a widget class)?

Let's take for example a pushbutton with the 'clicked' event. Event-Handler callback is 'on_<pbName>_clicked' - but PushButton has no function called on_clicked. It has a 'clicked' method and a 'do_clicked' method. Which one is appropriate to overload?
Last edit: 28 Jun 2019 12:36 by Reinhard.

Please Log in or Create an account to join the conversation.

More
28 Jun 2019 13:53 #138119 by cmorley
Replied by cmorley on topic GScreen learning: what happens at widget.connect() ?
maybe this will help for signal handling:
docs.huihoo.com/pygtk/2.0-tutorial/ch-Ad...dSignalHandling.html

comes from here::
docs.huihoo.com/pygtk/2.0-tutorial/index.html

another reference for widgets:
developer.gnome.org/pygtk/stable/

Chris M

Please Log in or Create an account to join the conversation.

More
29 Jun 2019 06:23 - 29 Jun 2019 06:28 #138159 by Reinhard
Replied by Reinhard on topic GScreen and some understanding gap of hal-widgets
Hi Chris,

thank you for the links. Nothing new or unknown so far and nothing to answer my questions ...
Anyway - I was able to create my first widget - with the help of hal_widget so far! :)
It works, but it has a really annoying behaviour - any time I replace the button with an image, the widget is about to resize. Hell! :(
I already copy all properties from one widget to the other - but that does not help anything.

Does anybody know a solution to prevent the resizing of the widget?
I create the screen for fullscreen usage - so resizing should never be an issue or even happen at all.

On this sample I use a homogeneous table with size-request of 100x100 - my imageIcons have the size 100x100 - the ToggleButton the gets a size of 112x112 - but when I use a size-request of 112x112 the ToggleButton grows even further.
Usage of the buttons of the test app:
Button 1 - 3 change the background color of my widget
Button 8 simulates a hal-pinchange event (external toggling of the button)
Button 5 makes the widget unresponsive (I don't want to use set_sensitive, cause it changes color of the images)
Button 6 makes the widget responsive again


Any help is appreciated!
Attachments:
Last edit: 29 Jun 2019 06:28 by Reinhard.

Please Log in or Create an account to join the conversation.

More
29 Jun 2019 18:04 #138185 by cmorley
Replied by cmorley on topic GScreen and some understanding gap of hal-widgets
I can't say for sure without a lot of experimenting what the resize problem is - I would guess the removing and inserting of widgets is the cause.
You might be able to explicitly set the size programmatically after insertion, you may need to .hide() .show() the widget..

Is it a toggle button with images that change on external events, or an image that changes on external events that you are looking to make?
The fact you are (in handleWidges) removing/inserting widgets from a container seems complicated.

You should be able to change the image on a button with .set_image()

here is an example (that I didn't try but shows the idea):
mport gtk

win = gtk.Window()
image_add = gtk.Image()
image_rem = gtk.Image()
b = gtk.Button()

image_add.set_from_stock(gtk.STOCK_ADD, gtk.ICON_SIZE_BUTTON)
image_rem.set_from_stock(gtk.STOCK_REMOVE, gtk.ICON_SIZE_BUTTON)

def on_clicked(button):
    state = button.get_active()
    if state:
        button.set_image(image_rem)
    else:
        button.set_image(image_add)

# setup initial state
b.set_image(image_add)

# connect signals
b.connect('clicked', on_clicked)
win.connect('delete-event', gtk.main_quit)

win.add(b)
win.show_all()
gtk.main()

Please Log in or Create an account to join the conversation.

More
30 Jun 2019 05:24 - 30 Jun 2019 05:26 #138221 by Reinhard
Replied by Reinhard on topic GScreen and some understanding gap of hal-widgets
Hi Chris,

I already used 'button.set_image(...)'

The challenge was to remove the button (under the hood) without changing the shown picture.
I got it by changing the superclass from Eventbox to Notebook. Notebook will not resize on page flip, so ...
As Stack-widget is not available at the version used by linuxcnc, Notebook will be the closest try ...
I now have a misplacement of 1 pixel - not nice, but acceptable. At least at the moment ;)
So I can continue work and create other widgets ...
Last edit: 30 Jun 2019 05:26 by Reinhard.

Please Log in or Create an account to join the conversation.

More
30 Jun 2019 05:37 #138222 by cmorley
Replied by cmorley on topic GScreen and some understanding gap of hal-widgets

Hi Chris,

I already used 'button.set_image(...)'


Yes I saw that in your code - but you seemed to have missed the bigger point.
You seem to be having fun now. I'm interested to see your finished screen!

Chris M

Please Log in or Create an account to join the conversation.

  1. User Interfaces
  3. Other User Interfaces
  5. GScreen and some understanding gap of hal-widgets
Time to create page: 0.106 seconds
Powered by Kunena Forum