Code cleanup question
04 May 2021 19:40 - 04 May 2021 19:45 #207867
by gibsonc
Code cleanup question was created by gibsonc
Hi all
I have been lurking in the code for some time now, mostly out of curiosity and to learn something new on a project that I use.
I was thinking of learning a bit more by at least trying to assist with the python3 / gtk3 porting effort on Rene's limuxcmc branch.
Python2 is EOL. GTK2 is EOL and GTK3 is already several years old. It has to be done to move forward.
One thing that became clear is that there is quite a bit of orphan and fancy footwork code (to deal with python2/3) lying around and when opening Glade for example, so many widgets are deprecated or have deprecated properties (some relatively easily rectified.)
Sure they can still be used in the short term, but the warnings hurt ones eyes
I haven't been able to find a clear answer in the forums. Does this project have a plan to get brutal and clean up properly, knowing that we may break a few things in the short term? Silly example: the HBox widget was removed in 2013 already because you can use a 1x1 table instead, which under GTK3 is actually now a Grid widget since the Table widget is deprecated. The code for HBox however is still there, I presume to satisfy some legacy requirement while not being visible to users to be used for new development.
I have been lurking in the code for some time now, mostly out of curiosity and to learn something new on a project that I use.
I was thinking of learning a bit more by at least trying to assist with the python3 / gtk3 porting effort on Rene's limuxcmc branch.
Python2 is EOL. GTK2 is EOL and GTK3 is already several years old. It has to be done to move forward.
One thing that became clear is that there is quite a bit of orphan and fancy footwork code (to deal with python2/3) lying around and when opening Glade for example, so many widgets are deprecated or have deprecated properties (some relatively easily rectified.)
Sure they can still be used in the short term, but the warnings hurt ones eyes
I haven't been able to find a clear answer in the forums. Does this project have a plan to get brutal and clean up properly, knowing that we may break a few things in the short term? Silly example: the HBox widget was removed in 2013 already because you can use a 1x1 table instead, which under GTK3 is actually now a Grid widget since the Table widget is deprecated. The code for HBox however is still there, I presume to satisfy some legacy requirement while not being visible to users to be used for new development.
Last edit: 04 May 2021 19:45 by gibsonc.
Please Log in or Create an account to join the conversation.
04 May 2021 22:13 #207884
by andypugh
Replied by andypugh on topic Code cleanup question
Ideally we would make a clean break in LinuxCNC 2.9.
But, does what you suggest mean that existing .ui files will cease to work? That would cause a great deal of user dissatisfaction if the update broke their existing panels. Can you think of a way round this?
(When we made large changes to the INI file layout and HAL pin names between 2.7 and 2.8 we introduced an automatic conversion script)
But, does what you suggest mean that existing .ui files will cease to work? That would cause a great deal of user dissatisfaction if the update broke their existing panels. Can you think of a way round this?
(When we made large changes to the INI file layout and HAL pin names between 2.7 and 2.8 we introduced an automatic conversion script)
Please Log in or Create an account to join the conversation.
05 May 2021 06:57 #207934
by gibsonc
Replied by gibsonc on topic Code cleanup question
Thanks Andy
I started playing around and found that it tends to mess up things like alignment but does not completely break the panels. That said I only scratched the surface. I didn't want to invest too much effort in a futile exercise, hence my question.
I completely understand the user experience concern. We are going through a similar transition at work redeveloping a system dating back to 2003 and having to manage user expectations and fears. It was however just not an option to keep dragging along legacy code. It makes it near impossible to onboard new developers, innovate, add features and move forward.
When you say existing panels, are you referring to user created panels or the ones included in the distribution which I believe one would at a minimum need to ensure that they remain functional?
Let me experiment a bit more and try to map out the challenges one can expect.
I started playing around and found that it tends to mess up things like alignment but does not completely break the panels. That said I only scratched the surface. I didn't want to invest too much effort in a futile exercise, hence my question.
I completely understand the user experience concern. We are going through a similar transition at work redeveloping a system dating back to 2003 and having to manage user expectations and fears. It was however just not an option to keep dragging along legacy code. It makes it near impossible to onboard new developers, innovate, add features and move forward.
When you say existing panels, are you referring to user created panels or the ones included in the distribution which I believe one would at a minimum need to ensure that they remain functional?
Let me experiment a bit more and try to map out the challenges one can expect.
Please Log in or Create an account to join the conversation.
05 May 2021 07:27 #207938
by andypugh
I am thinking of user-created panels, including any out in the wild, and also possibly scattered around the forum and the wiki.
The panels that are part of the distribution are under our control, and can be fixed.
I think that Rene (at a minimum) needs to be included in this discussion.
Replied by andypugh on topic Code cleanup question
When you say existing panels, are you referring to user created panels or the ones included in the distribution which I believe one would at a minimum need to ensure that they remain functional?
I am thinking of user-created panels, including any out in the wild, and also possibly scattered around the forum and the wiki.
The panels that are part of the distribution are under our control, and can be fixed.
I think that Rene (at a minimum) needs to be included in this discussion.
Please Log in or Create an account to join the conversation.
05 May 2021 14:11 #207971
by cmorley
Replied by cmorley on topic Code cleanup question
I think the switch to python/gtk3 is an excellent time to allow breaking of panels and code cleanup.
The GTK change will even require a different Glade editor.
Chris
The GTK change will even require a different Glade editor.
Chris
Please Log in or Create an account to join the conversation.
05 May 2021 15:29 #207982
by andypugh
Do you know if there is any kind of upgrade path by loading existing screens into the new editor and re-saving?
Replied by andypugh on topic Code cleanup question
I think the switch to python/gtk3 is an excellent time to allow breaking of panels and code cleanup.
The GTK change will even require a different Glade editor.
Do you know if there is any kind of upgrade path by loading existing screens into the new editor and re-saving?
Please Log in or Create an account to join the conversation.
05 May 2021 20:55 #208020
by newbynobi
Replied by newbynobi on topic Code cleanup question
I do not know a way ro update gtk2 panel to gtk3.
I spent a lot of time triing to change gmoccapy from py2 gtk2 to py3 gtk3, but I run into huge problems. Just to mention one, the color handling of the ui is completely different and Also the style is now handled over csv files.
That is the reason I stopped that PROJECT!
I decided to begin better from scratch as soon as possible, even gmoccapy is already running on py3 and gtk3 with some bugs left.
So Imho a complete brake is the only reasonable solution.
Norbert
I spent a lot of time triing to change gmoccapy from py2 gtk2 to py3 gtk3, but I run into huge problems. Just to mention one, the color handling of the ui is completely different and Also the style is now handled over csv files.
That is the reason I stopped that PROJECT!
I decided to begin better from scratch as soon as possible, even gmoccapy is already running on py3 and gtk3 with some bugs left.
So Imho a complete brake is the only reasonable solution.
Norbert
Please Log in or Create an account to join the conversation.
05 May 2021 22:52 #208035
by cmorley
unfortunately I know of no automated way to do that.
Replied by cmorley on topic Code cleanup question
I think the switch to python/gtk3 is an excellent time to allow breaking of panels and code cleanup.
The GTK change will even require a different Glade editor.
Do you know if there is any kind of upgrade path by loading existing screens into the new editor and re-saving?
unfortunately I know of no automated way to do that.
Please Log in or Create an account to join the conversation.
05 May 2021 23:56 #208045
by andypugh
I think that we have to go to Py3, but this is sounding like we have to accept (potentially) breaking every existing User config which has a GladeVCP tab?
Does PyVCP still work, or is that dead too?
Our project is unusually sensitive to this, we have many users who are not-programmers, running configs built for them by half-programmers, and a long, long, tail of legacy installs.
We can't really rely on the users to fix the problems that the Python and GTK developers have forced on us.
We have tried fairly hard to make it not the case that you have to be a programmer to run LinuxCNC. it would be a shame to lose that progress. [1]
[1] Well, maybe not, it isn't like there is _any_ benefit for existing users in more new users, and it's a positive detriment for the support/dev team to have vast quantities of users. Taken to the limit my life would be so much simpler were I the only living LinuxCNC user.
Replied by andypugh on topic Code cleanup question
[unfortunately I know of no automated way to do that.
I think that we have to go to Py3, but this is sounding like we have to accept (potentially) breaking every existing User config which has a GladeVCP tab?
Does PyVCP still work, or is that dead too?
Our project is unusually sensitive to this, we have many users who are not-programmers, running configs built for them by half-programmers, and a long, long, tail of legacy installs.
We can't really rely on the users to fix the problems that the Python and GTK developers have forced on us.
We have tried fairly hard to make it not the case that you have to be a programmer to run LinuxCNC. it would be a shame to lose that progress. [1]
[1] Well, maybe not, it isn't like there is _any_ benefit for existing users in more new users, and it's a positive detriment for the support/dev team to have vast quantities of users. Taken to the limit my life would be so much simpler were I the only living LinuxCNC user.
Please Log in or Create an account to join the conversation.
- BeagleBrainz
- Offline
- User is blocked
Less
More
- Posts: 1437
- Thank you received: 570
06 May 2021 01:29 #208058
by BeagleBrainz
Replied by BeagleBrainz on topic Code cleanup question
Maybe UI in C or CPP?
Please Log in or Create an account to join the conversation.
Moderators: HansU
Time to create page: 0.085 seconds