[Emc-developers] QTvcp 4/5 opinions wanted.

[Chris Morley]

I've been working on a branch that would supply linuxcnc with a python QT based vcp program.

This is capable of GLADEvcp type panels and operator screens including python handler files.

Qt seems to be the future of GUIs


The questions I am wonder on are:


python 2 or 3 ?


PYQT4 or 5 ?


Currently it's built with python 2 and PYQT4.


My personal opinion is that I see little reason to use python 3 yet - it seems many libraries are slow to switch.


QT5 is not available in wheezy but is available in Mint (a fairly common used distribution)

Looks like debian Jessie has PYQT5 in both styles of python.


So to use QT5 we would not be able to use QTvcp in wheezy and i would need some make file help

to juggle when to build and not.


I haven't read any significant differences between qt4/5 I just would like to future proof the work.

it's really disappointing the debacle of GTK2 and 3.


Opinions other comments?


Chris M

[EBo]

On Apr 18 2017 2:55 AM, Chris Morley wrote:
> I've been working on a branch that would supply linuxcnc with a
> python QT based vcp program.
>
> This is capable of GLADEvcp type panels and operator screens
> including python handler files.

for clarity, I am assuming that vcp stands for virtual control panel.

> Qt seems to be the future of GUIs
>
>
> The questions I am wonder on are:
>
>
> python 2 or 3 ?

if you are careful you can write it for both. Use the v3 print ism's
and try/except for the package/language dependencies.

> PYQT4 or 5 ?

what is the long term support of v4? Otherwise if you do not go with
v5 you are stuck porting in a year or two.

> Currently it's built with python 2 and PYQT4.
>
>
> My personal opinion is that I see little reason to use python 3 yet -
> it seems many libraries are slow to switch.

compatibility note above...

> QT5 is not available in wheezy but is available in Mint (a fairly
> common used distribution)
>
> Looks like debian Jessie has PYQT5 in both styles of python.
>
>
> So to use QT5 we would not be able to use QTvcp in wheezy and i
> would need some make file help

Do we have any sense for how that would impact development? Is there
any planned support for wheezy?

> to juggle when to build and not.
>
>
> I haven't read any significant differences between qt4/5 I just
> would like to future proof the work.

I would say this is the kicker. If upgrading from v4 to v5 is
painless, then there is no worries. Otherwise you have to make a
decision. How hard would it be to implement a migration test?

> it's really disappointing the debacle of GTK2 and 3.
>
>
> Opinions other comments?

Best of luck, and I truly hope you do not find yourself descending to
the 5'th level of dependency hell.

EBo --

[Gene Heskett]

On Tuesday 18 April 2017 04:55:58 Chris Morley wrote:

> I've been working on a branch that would supply linuxcnc with a python
> QT based vcp program.
>
> This is capable of GLADEvcp type panels and operator screens including
> python handler files.
>
> Qt seems to be the future of GUIs
>
>
> The questions I am wonder on are:
>
>
> python 2 or 3 ?
>
>
> PYQT4 or 5 ?
>
>
> Currently it's built with python 2 and PYQT4.
>
>
> My personal opinion is that I see little reason to use python 3 yet -
> it seems many libraries are slow to switch.
>
>
> QT5 is not available in wheezy but is available in Mint (a fairly
> common used distribution)
>
> Looks like debian Jessie has PYQT5 in both styles of python.
>
>
> So to use QT5 we would not be able to use QTvcp in wheezy and i would
> need some make file help
>
While my 3 wheezy x86 installs are running well, the end of support for
wheezy is in sight. Raspbian/jessie is running moderately well with an
occasional gui lockup. Keeping its gui busy seems to be key for long
uptimes.
> to juggle when to build and not.
>
>
> I haven't read any significant differences between qt4/5 I just would
> like to future proof the work.
>
> it's really disappointing the debacle of GTK2 and 3.
"debacle" is an understatement. I get the impression that they fully
intended to throw it under the bus.

The python list is, and has been for at least a year, recommending that
all new python work be based on python 3.5 or better. The configure/make
should prefer to use QT5 if available, or QT4 if thats whats available.
How difficult to accomplish that remains TBS.

Of one thing I am sure, and that is if gladevcp functionality can be
brought back using QT, there will be cheering and clapping from the
bleachers where I sit.

Thank you Chris.
>
>
> Opinions other comments?
>
>
> Chris M
> ----------------------------------------------------------------------
>-------- Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Emc-developers mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Chris Morley]

> I haven't read any significant differences between qt4/5 I just would
> like to future proof the work.
>
> it's really disappointing the debacle of GTK2 and 3.
"debacle" is an understatement. I get the impression that they fully
intended to throw it under the bus.

The python list is, and has been for at least a year, recommending that
all new python work be based on python 3.5 or better. The configure/make
should prefer to use QT5 if available, or QT4 if thats whats available.
How difficult to accomplish that remains TBS.

Of one thing I am sure, and that is if gladevcp functionality can be
brought back using QT, there will be cheering and clapping from the
bleachers where I sit.

Thank you Chris.
>
>
> Opinions other comments?
>

Python will always recommend the lastest greatest just as we do.
The fact is that using something a bit older is usually way more stable.
python 2.x and qt4.x will be around for a long time yet.

The GTK/GLADE problem is not completely their fault - we are using GLADE in a way
that is not common or probably even thought of. - building new screens often for the same
program.
We also happened to create gladeVCP close to a time were the API change drastically.
Well 2.7 took a long time to come out (IIRC) so really it seems worse to users then developers.

really gladeVCP it's self will work for a very long time yet - it's the fact the GLADE editor changed
that has screwed us up - they dropped the ball on not allowing reading and writing of different
versions.

I also have a branch that was 90% usable with GTK3 the stumbling block was gremlin - which
the library has not be converted to GTK3 - one has to use a different library.
I did some work on that but it's a bit beyond my patients. I asked for help and it seems no-one
was interested.

QT as I understand it did similar thing between versions 2 and 3 but of late are much more interested
in backward compatibility.

I'm personally not interested in making QTvcp work with both QT4 and QT5.

Chris M

[andy pugh]

On 18 April 2017 at 09:55, Chris Morley <***@hotmail.com> wrote:
> it's really disappointing the debacle of GTK2 and 3.

Yes. I like what we can do with GladeVCP but the fact is that there
seems to be absolutely no support to be had at all.
I had a problem with pyGTK and got no reply at all on the mailing
list, or on their IRC, or even sending emails to the professional
developers listed on the pyGTK home page under "consulting"

The pygtk email list archives are here:
http://mailman.daa.com.au/cgi-bin/pipermail/pygtk/ You will see that
it is a write-only medium.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

[Gene Heskett]

On Tuesday 18 April 2017 07:38:22 andy pugh wrote:

> On 18 April 2017 at 09:55, Chris Morley <***@hotmail.com>
wrote:
> > it's really disappointing the debacle of GTK2 and 3.
>
> Yes. I like what we can do with GladeVCP but the fact is that there
> seems to be absolutely no support to be had at all.
> I had a problem with pyGTK and got no reply at all on the mailing
> list, or on their IRC, or even sending emails to the professional
> developers listed on the pyGTK home page under "consulting"
>
> The pygtk email list archives are here:
> http://mailman.daa.com.au/cgi-bin/pipermail/pygtk/ You will see that
> it is a write-only medium.

Such does seem to be discouraging, Andy.

Are we as a group, destined to develop our own version of a gui helper?
The things we need seem to be of zero interest to the crowd of what I
call "drive by" coders for lack of a more descriptive term. They were
for the most part, scratching an itch of their own, and once
sufficiently scratched, the key is twisted and down the road they go,
leaving no means of obtaining any support when a linked library
is "cleaned up" by someone else scratching their own personal itch.

The problem as I see it, is 100% TANSTAAFL.

pyvcp seems to be the longest surviving gui dialect, and I have to assume
it is 100% our own groups code, not having encountered it elsewhere to
my knowledge, but it has some lacks. But the fact that a function can
still be coded and made to work, such as Kurt's "units" that I was
chasing recently, is an example of what some of us can do when we have
an itch. So I would suggest that all of us should be contributing to
the wiki so that WE will have our own support, filling in the gaps in
pyvcp until we have all of our itches scratched. 'twill never happen of
course because each new feature opens up the possibility of doing even
more, so there is yet another itch to scratch.

The wiki seems to be a victim of not enough TLC. It seriously needs a
whats new category that links to the most recent 20 commits as that
would bring the gems to our attention w/o having to concoct a search
string.

I _should_ be working on separating out my jog dial code so that it
becomes a postgui hal file and its matching .xml file, and get that
committed to the wiki. But with all its comments just so I can track it
myself, its likely to be close to 500 LOC. More than the hal file
itself without the jogging. One more module to swap out, and make
Kurts "units" switch the jog increments to metric with another mult2,
then some cut and paste (I hope) should realize that. But first, make
some swarf with it as I don't have a working spindle crank. Bearings s/b
be here later today (according to amazon's web page)...

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[dragon]

My vote would be for QT5 and trying to write for python 2 AND 3
compatibility of the code. Of course I'm not the one writing it though.

My personal opinion is that LinuxCNC builds for wheezy need to be
relegated to bug fixes and such and all new features 'officially'
supported on only newer OS releases. Support for wheezy from the Debian
project ends in a year, and stretch has now gone into feature freeze.
The five year old hardware driver set in wheezy exhibits less than
desirable results on many newer motherboards and graphics cards in my
experience and I often end up pulling things from backports.

I have always preferred QT over GTK... It would be wonderful to have this!



On 04/18/2017 03:55 AM, Chris Morley wrote:
> I've been working on a branch that would supply linuxcnc with a python QT based vcp program.
>
> This is capable of GLADEvcp type panels and operator screens including python handler files.
>
> Qt seems to be the future of GUIs
>
>
> The questions I am wonder on are:
>
>
> python 2 or 3 ?
>
>
> PYQT4 or 5 ?
>
>
> Currently it's built with python 2 and PYQT4.
>
>
> My personal opinion is that I see little reason to use python 3 yet - it seems many libraries are slow to switch.
>
>
> QT5 is not available in wheezy but is available in Mint (a fairly common used distribution)
>
> Looks like debian Jessie has PYQT5 in both styles of python.
>
>
> So to use QT5 we would not be able to use QTvcp in wheezy and i would need some make file help
>
> to juggle when to build and not.
>
>
> I haven't read any significant differences between qt4/5 I just would like to future proof the work.
>
> it's really disappointing the debacle of GTK2 and 3.
>
>
> Opinions other comments?
>
>
> Chris M
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Emc-developers mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

[John Thornton]

Hi Chris,

For Master I'd go with python 2 or 3, it seems to be very little
difference writing for both.

http://python-future.org/compatible_idioms.html

And for PyQT I'd vote for 5.

as others have said 2.7 and wheezy are in the past.

Just my 2.625 cents.

JT


On 4/18/2017 3:55 AM, Chris Morley wrote:
> I've been working on a branch that would supply linuxcnc with a python QT based vcp program.
>
> This is capable of GLADEvcp type panels and operator screens including python handler files.
>
> Qt seems to be the future of GUIs
>
>
> The questions I am wonder on are:
>
>
> python 2 or 3 ?
>
>
> PYQT4 or 5 ?
>
>
> Currently it's built with python 2 and PYQT4.
>
>
> My personal opinion is that I see little reason to use python 3 yet - it seems many libraries are slow to switch.
>
>
> QT5 is not available in wheezy but is available in Mint (a fairly common used distribution)
>
> Looks like debian Jessie has PYQT5 in both styles of python.
>
>
> So to use QT5 we would not be able to use QTvcp in wheezy and i would need some make file help
>
> to juggle when to build and not.
>
>
> I haven't read any significant differences between qt4/5 I just would like to future proof the work.
>
> it's really disappointing the debacle of GTK2 and 3.
>
>
> Opinions other comments?
>
>
> Chris M
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Emc-developers mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers

[Nicklas Karlsson]

I bought an old CNC machine a while ago, I turned on the button and the text instantly displayed on the screen, how much time does it take today with a lot faster computer?



On Tue, 18 Apr 2017 08:55:58 +0000
Chris Morley <***@hotmail.com> wrote:

> I've been working on a branch that would supply linuxcnc with a python QT based vcp program.
>
> This is capable of GLADEvcp type panels and operator screens including python handler files.
>
> Qt seems to be the future of GUIs
>
>
> The questions I am wonder on are:
>
>
> python 2 or 3 ?
>
>
> PYQT4 or 5 ?
>
>
> Currently it's built with python 2 and PYQT4.
>
>
> My personal opinion is that I see little reason to use python 3 yet - it seems many libraries are slow to switch.
>
>
> QT5 is not available in wheezy but is available in Mint (a fairly common used distribution)
>
> Looks like debian Jessie has PYQT5 in both styles of python.
>
>
> So to use QT5 we would not be able to use QTvcp in wheezy and i would need some make file help
>
> to juggle when to build and not.
>
>
> I haven't read any significant differences between qt4/5 I just would like to future proof the work.
>
> it's really disappointing the debacle of GTK2 and 3.
>
>
> Opinions other comments?
>
>
> Chris M
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Emc-developers mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers

[Jon Elson]

On 04/18/2017 01:30 PM, Nicklas Karlsson wrote:
> I bought an old CNC machine a while ago, I turned on the button and the text instantly displayed on the screen, how much time does it take today with a lot faster computer?
>
>
Yes, my Allen-Bradley 7320 control, which I used before the
original EMC, was pretty close to "instant on".
You pressed "control on", waited a second for some relays to
click, and then pressed "estop reset" and you could start
jogging before the CRT warmed up enough to give a display.
That is, if it came up. It had a bad habit of dumping the
battery-backed memory every few weeks, so you had to reload
the executive from a laptop pretending to be a paper tape
reader. Then, you had to load the part program from the laptop.

Well, LinuxCNC is SO MUCH more reliable, capable and usable,
that I never want to go back! So, I don't really begrudge a
minute to boot up. I can pump the lube handle and get a few
other things ready while Linux is booting.

Jon

[Eric Keller]

On Tue, Apr 18, 2017 at 9:51 PM, Jon Elson <***@pico-systems.com> wrote:

> So, I don't really begrudge a
> minute to boot up. I can pump the lube handle and get a few
> other things ready while Linux is booting.
>

Linux boots pretty fast from an SSD. We have an accurite machine from the
'90s at work. It's funny to see the bios messages come up on that, I think
it has a 486. Dos booted pretty fast, I think that's probably what it's
running.

[Nicklas Karlsson]

> On 04/18/2017 01:30 PM, Nicklas Karlsson wrote:
> > I bought an old CNC machine a while ago, I turned on the button and the text instantly displayed on the screen, how much time does it take today with a lot faster computer?
> >
> >
> Yes, my Allen-Bradley 7320 control, which I used before the
> original EMC, was pretty close to "instant on".
> You pressed "control on", waited a second for some relays to
> click, and then pressed "estop reset" and you could start
> jogging before the CRT warmed up enough to give a display.
> That is, if it came up. It had a bad habit of dumping the
> battery-backed memory every few weeks, so you had to reload
> the executive from a laptop pretending to be a paper tape
> reader. Then, you had to load the part program from the laptop.
>
> Well, LinuxCNC is SO MUCH more reliable, capable and usable,
> that I never want to go back! So, I don't really begrudge a
> minute to boot up. I can pump the lube handle and get a few
> other things ready while Linux is booting.
>
> Jon

I should change to linuxcnc but it still make me think, it have become slower.

[Jon Elson]

On 04/19/2017 10:42 AM, Nicklas Karlsson wrote:
>>
> I should change to linuxcnc but it still make me think, it have become slower.
>
>
It is possible to make systems boot a lot faster. Much of
the time is spent checking if it needs to load drivers for
non-existent hardware. If you take all the scripts that try
those various devices and services out of the boot-up
sequence, it can boot a lot faster. With NO changes, my
laptop boots to the login prompt in 15 seconds, with an SSD.
Some people say they can get Linux systems to boot in just a
couple seconds by removing the unnecessary stuff.

Just the graphical preview is worth LOTS to me, to make sure
I have loaded the correct part program. Soft limits is
another great thing. It lets you know that the part program
exceeds the machine travel before the first move, saves a
lot of trouble, wrecked workpieces, etc.

Jon