qtvcp issues

Ok pushed fix.
also added geometry memory for the ToolOffsetsDialog widget.
See if that is a step in the right direction.


Chris M

So after a little experimental work I can make them honour the designer placement.
I'll see about making that work for you soon.

Chris M

The spelling error is fixed.

I put ToolOffsetsDialog in my frame at x0 y0 and it came back at x2150 y321 the first time and x2280 y307 the second time. My requested size came back ok when I used min/max size entries (600x400).

Ok I hadn't commit the honour-designer-positions yet.
I just did so:

In general the idea is:
With a clean preference file the dialogs will show where you put them in designer.
If a user moves them it will remember this and next time show them there.

If a user wants them to always start in a specific position (even if he moves them) then he can change the entry in the preference file.
The are some commands: default,center,bottomleft

so if in your preference file you had (the x,y, width,height):
CamViewDialog-geometry = 562 201 758 602

if you changed that to
CamViewDialog-geometry = center
Then it will always start in the middle, it will use it's designer defined with and height

If you want to make the screen ignore the preference file altogether then you can do that in the handler file like so:
under the 'Special Functions called from QTVCP' hearder
find the function: def initialized__(self):
add something like this:
self.w.tooloffsetdialog._geometry_string='100 100 800 200 h'
(note the letter here doesn't matter and non digit will do)
or
self.w.tooloffsetdialog._geometry_string='center'
or
self.w.tooloffsetdialog._geometry_string='default''
etc.

The shutdown dialog (or any that use the generic LcncDialog widget) still only shows in the center.

Try it out see what you think - it may need more work yet.

Chris M

I'll just remind you that you need to clear any geometry entries in the preference file from your last test, or the dialog may follow them.

Well onboard does load, at least in Mint 13:



Chris M

Nice, the keyboard looks great I will see if I can get it to show up in my stackedWidget_2 index 1 later today. Is there some thing special that needs to be done to get it to load? My stackedWidget_2 index 1 has space for 954x228 objects which I figured was large enough for a key board.

I will also try out the other changes you have made after I get done doing some button work between the gui .ui file and the handler. I will go ahead a do a pull now.

I added a layout widget, then the XEmbed widget, change the command property to onboard --xid

I think i added a spacer widget to make the keyboard a bit better size.

Chris M

Well it seems while the keyboard a;ways embeds..it doesn't work consistently - at least for me.

Chris M

I would think that if the keyboard does not work constantly that is a good chance that its a timing related issue. I have not had a chance to look at it.

Ran into a little problem with push button action to bring up a page when used with python cmd string and is checked in checkable.

True cmd string: INSTANCE.stackedWidget_2.setCurrentIndex(1)
False cnd string: INSTANCE.stackedWidget_2.setCurrentIndex(0)

The thought is that the button should act like a toggle button, push on, push off. But as soon as the mouse is released from pushing the button to the on state it sends the false cmd with the button indicating that it is still in the true state. Thus it sends commands improperly under this condition.

I would like to have the keyboard pop up like mdi and file editing modes are selected but have it selectable whether to do that or not via another button.