Discussion:
tooledit_widget modifications
(too old to reply)
Jim Craig
2016-12-23 03:02:16 UTC
Permalink
Raw Message
I use gmoccapy on my milling machine. I really like that gui. Thanks
Norbert!

The one thing that I think is lacking is the way the tool table works.
It is based on the tooledit_widget. It is a real pain to modify the tool
table while in gmoccapy. To edit an entry you must check the line you
want to edit, click on the cell that you want to edit change the value
then you must press enter to accept the value. To edit another value you
have to click on that cell, edit the value and press enter. Sorry
cmorely, not bashing on your widget. I just want to make it better.

This is not the way I normally edit a table. I use tab and enter and
arrow keys to navigate a table. I have made some tweaks to the
tooledit_widget.py and tooledit_gtk.glade to allow the tab key to accept
the value in the current cell and advance to the next visible cell on
the current row. I have also made all cells editable without having to
have the checkbox in the first column checked. Also the Return key or
the keypad enter key will accept the value in the current cell and
progress to the same cell in the next row of the table. This makes
navigating the table so much easier and faster.

I can add in the arrow key movements as well. I have not done that yet
but I can sure do it.

I am trying to get my RIP install working but I am having issues per my
other emails. Once I test it in a sim gmoccapy then I will be ready to
put it on git if you all agree.

Let me know if you have any questions or comments.

Thanks,

Jim
Jim Craig
2016-12-26 23:53:19 UTC
Permalink
Raw Message
I have the tooledit widget working as I like. This is the first time I
have wanted to publish my work on the project. What is the appropriate
method for me publishing the modified files?

I have been reading the section on contributing to linuxcnc but I am a
bit confused at this point. Do I make my modifications in a fork of the
linuxcnc project under my username, or do I make the modifications in a
branch within the linuxcnc project?

I have already forked linuxcnc to my username. I have cloned the fork to
my machine. Modified the files on my machine. Built a RIP linuxcnc based
on the modified code. Ran the runtest command on the new build with no
errors. Tested the functionality and It is working as I was wanting.

I believe the next step is to put my modified code to my linuxcnc fork
but I am not sure.

Please let me know what the next step is.

Also I think this modification could be published in the 2.7 branch as
well as master. Currently I have been working with a copy of master.
Should I publish the files to the 2.7 branch?

Thanks,

Jim

On 12/22/2016 9:02 PM, Jim Craig wrote:
> I use gmoccapy on my milling machine. I really like that gui. Thanks
> Norbert!
>
> The one thing that I think is lacking is the way the tool table works.
> It is based on the tooledit_widget. It is a real pain to modify the
> tool table while in gmoccapy. To edit an entry you must check the line
> you want to edit, click on the cell that you want to edit change the
> value then you must press enter to accept the value. To edit another
> value you have to click on that cell, edit the value and press enter.
> Sorry cmorely, not bashing on your widget. I just want to make it better.
>
> This is not the way I normally edit a table. I use tab and enter and
> arrow keys to navigate a table. I have made some tweaks to the
> tooledit_widget.py and tooledit_gtk.glade to allow the tab key to
> accept the value in the current cell and advance to the next visible
> cell on the current row. I have also made all cells editable without
> having to have the checkbox in the first column checked. Also the
> Return key or the keypad enter key will accept the value in the
> current cell and progress to the same cell in the next row of the
> table. This makes navigating the table so much easier and faster.
>
> I can add in the arrow key movements as well. I have not done that yet
> but I can sure do it.
>
> I am trying to get my RIP install working but I am having issues per
> my other emails. Once I test it in a sim gmoccapy then I will be ready
> to put it on git if you all agree.
>
> Let me know if you have any questions or comments.
>
> Thanks,
>
> Jim
>
Jim Craig
2016-12-28 03:00:16 UTC
Permalink
Raw Message
I committed the updated code to my fork of the project at
https://github.com/LearningLinuxCNC/linuxcnc

I put in a pull request to the linuxcnc project.

The updated code allows for normal spreadsheet navigation and editing of
the table. Tab and right arrow accepts the value in the current cell and
moves to the next visible cell to the right. If the current active cell
is the last cell on the row then it moves to the first visible cell on
the row. Left arrow key works the same except in the left direction.
Enter and down arrow accepts the value in the current cell and moves
down one row in the same column. If on the last row then it will move to
the first row in the table. The up arrow works the same except in the up
direction.

Let me know if I need to do anything different. Again first timer here
so trying to figure out the correct process here.

Thanks,

Jim

On 12/26/2016 5:53 PM, Jim Craig wrote:
> I have the tooledit widget working as I like. This is the first time I
> have wanted to publish my work on the project. What is the appropriate
> method for me publishing the modified files?
>
> I have been reading the section on contributing to linuxcnc but I am a
> bit confused at this point. Do I make my modifications in a fork of
> the linuxcnc project under my username, or do I make the modifications
> in a branch within the linuxcnc project?
>
> I have already forked linuxcnc to my username. I have cloned the fork
> to my machine. Modified the files on my machine. Built a RIP linuxcnc
> based on the modified code. Ran the runtest command on the new build
> with no errors. Tested the functionality and It is working as I was
> wanting.
>
> I believe the next step is to put my modified code to my linuxcnc fork
> but I am not sure.
>
> Please let me know what the next step is.
>
> Also I think this modification could be published in the 2.7 branch as
> well as master. Currently I have been working with a copy of master.
> Should I publish the files to the 2.7 branch?
>
> Thanks,
>
> Jim
>
> On 12/22/2016 9:02 PM, Jim Craig wrote:
>> I use gmoccapy on my milling machine. I really like that gui. Thanks
>> Norbert!
>>
>> The one thing that I think is lacking is the way the tool table
>> works. It is based on the tooledit_widget. It is a real pain to
>> modify the tool table while in gmoccapy. To edit an entry you must
>> check the line you want to edit, click on the cell that you want to
>> edit change the value then you must press enter to accept the value.
>> To edit another value you have to click on that cell, edit the value
>> and press enter. Sorry cmorely, not bashing on your widget. I just
>> want to make it better.
>>
>> This is not the way I normally edit a table. I use tab and enter and
>> arrow keys to navigate a table. I have made some tweaks to the
>> tooledit_widget.py and tooledit_gtk.glade to allow the tab key to
>> accept the value in the current cell and advance to the next visible
>> cell on the current row. I have also made all cells editable without
>> having to have the checkbox in the first column checked. Also the
>> Return key or the keypad enter key will accept the value in the
>> current cell and progress to the same cell in the next row of the
>> table. This makes navigating the table so much easier and faster.
>>
>> I can add in the arrow key movements as well. I have not done that
>> yet but I can sure do it.
>>
>> I am trying to get my RIP install working but I am having issues per
>> my other emails. Once I test it in a sim gmoccapy then I will be
>> ready to put it on git if you all agree.
>>
>> Let me know if you have any questions or comments.
>>
>> Thanks,
>>
>> Jim
>>
>
Tero Kaarlela
2016-12-28 05:13:48 UTC
Permalink
Raw Message
Hi,

This is a good one. Current tool table is awkward.

--
Tero Kaarlela
Production Engineer
Eka-Sorvaus OY
Nivala
Finland
mob +358 40 5906764
http://www.eka-sorvaus.fi


Tue, 27 Dec 2016 21:00:16 -0600 Jim Craig <***@windstream.net>
wrote:
> I committed the updated code to my fork of the project at
> https://github.com/LearningLinuxCNC/linuxcnc
>
> I put in a pull request to the linuxcnc project.
>
> The updated code allows for normal spreadsheet navigation and editing
> of the table. Tab and right arrow accepts the value in the current
> cell and moves to the next visible cell to the right. If the current
> active cell is the last cell on the row then it moves to the first
> visible cell on the row. Left arrow key works the same except in the
> left direction. Enter and down arrow accepts the value in the current
> cell and moves down one row in the same column. If on the last row
> then it will move to the first row in the table. The up arrow works
> the same except in the up direction.
>
> Let me know if I need to do anything different. Again first timer
> here so trying to figure out the correct process here.
>
> Thanks,
>
> Jim
>
> On 12/26/2016 5:53 PM, Jim Craig wrote:
> > I have the tooledit widget working as I like. This is the first
> > time I have wanted to publish my work on the project. What is the
> > appropriate method for me publishing the modified files?
> >
> > I have been reading the section on contributing to linuxcnc but I
> > am a bit confused at this point. Do I make my modifications in a
> > fork of the linuxcnc project under my username, or do I make the
> > modifications in a branch within the linuxcnc project?
> >
> > I have already forked linuxcnc to my username. I have cloned the
> > fork to my machine. Modified the files on my machine. Built a RIP
> > linuxcnc based on the modified code. Ran the runtest command on the
> > new build with no errors. Tested the functionality and It is
> > working as I was wanting.
> >
> > I believe the next step is to put my modified code to my linuxcnc
> > fork but I am not sure.
> >
> > Please let me know what the next step is.
> >
> > Also I think this modification could be published in the 2.7 branch
> > as well as master. Currently I have been working with a copy of
> > master. Should I publish the files to the 2.7 branch?
> >
> > Thanks,
> >
> > Jim
> >
> > On 12/22/2016 9:02 PM, Jim Craig wrote:
> >> I use gmoccapy on my milling machine. I really like that gui.
> >> Thanks Norbert!
> >>
> >> The one thing that I think is lacking is the way the tool table
> >> works. It is based on the tooledit_widget. It is a real pain to
> >> modify the tool table while in gmoccapy. To edit an entry you must
> >> check the line you want to edit, click on the cell that you want
> >> to edit change the value then you must press enter to accept the
> >> value. To edit another value you have to click on that cell, edit
> >> the value and press enter. Sorry cmorely, not bashing on your
> >> widget. I just want to make it better.
> >>
> >> This is not the way I normally edit a table. I use tab and enter
> >> and arrow keys to navigate a table. I have made some tweaks to the
> >> tooledit_widget.py and tooledit_gtk.glade to allow the tab key to
> >> accept the value in the current cell and advance to the next
> >> visible cell on the current row. I have also made all cells
> >> editable without having to have the checkbox in the first column
> >> checked. Also the Return key or the keypad enter key will accept
> >> the value in the current cell and progress to the same cell in the
> >> next row of the table. This makes navigating the table so much
> >> easier and faster.
> >>
> >> I can add in the arrow key movements as well. I have not done that
> >> yet but I can sure do it.
> >>
> >> I am trying to get my RIP install working but I am having issues
> >> per my other emails. Once I test it in a sim gmoccapy then I will
> >> be ready to put it on git if you all agree.
> >>
> >> Let me know if you have any questions or comments.
> >>
> >> Thanks,
> >>
> >> Jim
> >>
> >
>
>
> ------------------------------------------------------------------------------
> 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


--
Tero Kaarlela
Production Engineer
Eka-Sorvaus OY
Nivala
Finland
mob +358 40 5906764
http://www.eka-sorvaus.fi
Chris Morley
2016-12-28 07:24:45 UTC
Permalink
Raw Message
Hi Jim


This sounds like a great improvement (I haven't actually tried it)

The two ways of presenting one's work is forking or git patch.

On small stuff I personally prefer patching (I don't use github much so am rusty) - but it doesn't really matter.


As this is an upgrade (arguably) rather then a bug fix - it would usually go in master.
tooledit in master may be different - I can't remember - if so you may need to adapt your patch for it.

After that there is no real official way to guarantee inclusion or audit.
Since Norbert and I probably are most familiar with and use this widget we probably are the best people
to bug.
I will try to test your widget soon.

Chris M

________________________________
From: Jim Craig <***@windstream.net>
Sent: December 28, 2016 3:00 AM
To: EMC developers
Subject: Re: [Emc-developers] tooledit_widget modifications

I committed the updated code to my fork of the project at
https://github.com/LearningLinuxCNC/linuxcnc
[https://avatars2.githubusercontent.com/u/19329127?v=3&s=400]<https://github.com/LearningLinuxCNC/linuxcnc>

LearningLinuxCNC/linuxcnc<https://github.com/LearningLinuxCNC/linuxcnc>
github.com
linuxcnc - LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.




I put in a pull request to the linuxcnc project.

The updated code allows for normal spreadsheet navigation and editing of
the table. Tab and right arrow accepts the value in the current cell and
moves to the next visible cell to the right. If the current active cell
is the last cell on the row then it moves to the first visible cell on
the row. Left arrow key works the same except in the left direction.
Enter and down arrow accepts the value in the current cell and moves
down one row in the same column. If on the last row then it will move to
the first row in the table. The up arrow works the same except in the up
direction.

Let me know if I need to do anything different. Again first timer here
so trying to figure out the correct process here.

Thanks,

Jim

On 12/26/2016 5:53 PM, Jim Craig wrote:
> I have the tooledit widget working as I like. This is the first time I
> have wanted to publish my work on the project. What is the appropriate
> method for me publishing the modified files?
>
> I have been reading the section on contributing to linuxcnc but I am a
> bit confused at this point. Do I make my modifications in a fork of
> the linuxcnc project under my username, or do I make the modifications
> in a branch within the linuxcnc project?
>
> I have already forked linuxcnc to my username. I have cloned the fork
> to my machine. Modified the files on my machine. Built a RIP linuxcnc
> based on the modified code. Ran the runtest command on the new build
> with no errors. Tested the functionality and It is working as I was
> wanting.
>
> I believe the next step is to put my modified code to my linuxcnc fork
> but I am not sure.
>
> Please let me know what the next step is.
>
> Also I think this modification could be published in the 2.7 branch as
> well as master. Currently I have been working with a copy of master.
> Should I publish the files to the 2.7 branch?
>
> Thanks,
>
> Jim
>
> On 12/22/2016 9:02 PM, Jim Craig wrote:
>> I use gmoccapy on my milling machine. I really like that gui. Thanks
>> Norbert!
>>
>> The one thing that I think is lacking is the way the tool table
>> works. It is based on the tooledit_widget. It is a real pain to
>> modify the tool table while in gmoccapy. To edit an entry you must
>> check the line you want to edit, click on the cell that you want to
>> edit change the value then you must press enter to accept the value.
>> To edit another value you have to click on that cell, edit the value
>> and press enter. Sorry cmorely, not bashing on your widget. I just
>> want to make it better.
>>
>> This is not the way I normally edit a table. I use tab and enter and
>> arrow keys to navigate a table. I have made some tweaks to the
>> tooledit_widget.py and tooledit_gtk.glade to allow the tab key to
>> accept the value in the current cell and advance to the next visible
>> cell on the current row. I have also made all cells editable without
>> having to have the checkbox in the first column checked. Also the
>> Return key or the keypad enter key will accept the value in the
>> current cell and progress to the same cell in the next row of the
>> table. This makes navigating the table so much easier and faster.
>>
>> I can add in the arrow key movements as well. I have not done that
>> yet but I can sure do it.
>>
>> I am trying to get my RIP install working but I am having issues per
>> my other emails. Once I test it in a sim gmoccapy then I will be
>> ready to put it on git if you all agree.
>>
>> Let me know if you have any questions or comments.
>>
>> Thanks,
>>
>> Jim
>>
>


------------------------------------------------------------------------------
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
Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
lists.sourceforge.net
The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
Jim Craig
2016-12-28 21:01:09 UTC
Permalink
Raw Message
Chris,

Thanks for the feedback. I did the fork method this time. I did my work
based on the tooledit_widget in the master branch so I think we are good
to go.

In general should I work in the master branch on my fork, or should I
make a separate branch in my fork based on the master branch?

Let me know what you think. I was thinking about adding in the escape
key to restore the pre-edited value to the cell. What do you think about
that?

Thanks again,

Jim

On 12/28/2016 1:24 AM, Chris Morley wrote:
> Hi Jim
>
>
> This sounds like a great improvement (I haven't actually tried it)
>
> The two ways of presenting one's work is forking or git patch.
>
> On small stuff I personally prefer patching (I don't use github much so am rusty) - but it doesn't really matter.
>
>
> As this is an upgrade (arguably) rather then a bug fix - it would usually go in master.
> tooledit in master may be different - I can't remember - if so you may need to adapt your patch for it.
>
> After that there is no real official way to guarantee inclusion or audit.
> Since Norbert and I probably are most familiar with and use this widget we probably are the best people
> to bug.
> I will try to test your widget soon.
>
> Chris M
>
> ________________________________
> From: Jim Craig <***@windstream.net>
> Sent: December 28, 2016 3:00 AM
> To: EMC developers
> Subject: Re: [Emc-developers] tooledit_widget modifications
>
> I committed the updated code to my fork of the project at
> https://github.com/LearningLinuxCNC/linuxcnc
> [https://avatars2.githubusercontent.com/u/19329127?v=3&s=400]<https://github.com/LearningLinuxCNC/linuxcnc>
>
> LearningLinuxCNC/linuxcnc<https://github.com/LearningLinuxCNC/linuxcnc>
> github.com
> linuxcnc - LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.
>
>
>
>
> I put in a pull request to the linuxcnc project.
>
> The updated code allows for normal spreadsheet navigation and editing of
> the table. Tab and right arrow accepts the value in the current cell and
> moves to the next visible cell to the right. If the current active cell
> is the last cell on the row then it moves to the first visible cell on
> the row. Left arrow key works the same except in the left direction.
> Enter and down arrow accepts the value in the current cell and moves
> down one row in the same column. If on the last row then it will move to
> the first row in the table. The up arrow works the same except in the up
> direction.
>
> Let me know if I need to do anything different. Again first timer here
> so trying to figure out the correct process here.
>
> Thanks,
>
> Jim
>
> On 12/26/2016 5:53 PM, Jim Craig wrote:
>> I have the tooledit widget working as I like. This is the first time I
>> have wanted to publish my work on the project. What is the appropriate
>> method for me publishing the modified files?
>>
>> I have been reading the section on contributing to linuxcnc but I am a
>> bit confused at this point. Do I make my modifications in a fork of
>> the linuxcnc project under my username, or do I make the modifications
>> in a branch within the linuxcnc project?
>>
>> I have already forked linuxcnc to my username. I have cloned the fork
>> to my machine. Modified the files on my machine. Built a RIP linuxcnc
>> based on the modified code. Ran the runtest command on the new build
>> with no errors. Tested the functionality and It is working as I was
>> wanting.
>>
>> I believe the next step is to put my modified code to my linuxcnc fork
>> but I am not sure.
>>
>> Please let me know what the next step is.
>>
>> Also I think this modification could be published in the 2.7 branch as
>> well as master. Currently I have been working with a copy of master.
>> Should I publish the files to the 2.7 branch?
>>
>> Thanks,
>>
>> Jim
>>
>> On 12/22/2016 9:02 PM, Jim Craig wrote:
>>> I use gmoccapy on my milling machine. I really like that gui. Thanks
>>> Norbert!
>>>
>>> The one thing that I think is lacking is the way the tool table
>>> works. It is based on the tooledit_widget. It is a real pain to
>>> modify the tool table while in gmoccapy. To edit an entry you must
>>> check the line you want to edit, click on the cell that you want to
>>> edit change the value then you must press enter to accept the value.
>>> To edit another value you have to click on that cell, edit the value
>>> and press enter. Sorry cmorely, not bashing on your widget. I just
>>> want to make it better.
>>>
>>> This is not the way I normally edit a table. I use tab and enter and
>>> arrow keys to navigate a table. I have made some tweaks to the
>>> tooledit_widget.py and tooledit_gtk.glade to allow the tab key to
>>> accept the value in the current cell and advance to the next visible
>>> cell on the current row. I have also made all cells editable without
>>> having to have the checkbox in the first column checked. Also the
>>> Return key or the keypad enter key will accept the value in the
>>> current cell and progress to the same cell in the next row of the
>>> table. This makes navigating the table so much easier and faster.
>>>
>>> I can add in the arrow key movements as well. I have not done that
>>> yet but I can sure do it.
>>>
>>> I am trying to get my RIP install working but I am having issues per
>>> my other emails. Once I test it in a sim gmoccapy then I will be
>>> ready to put it on git if you all agree.
>>>
>>> Let me know if you have any questions or comments.
>>>
>>> Thanks,
>>>
>>> Jim
>>>
>
> ------------------------------------------------------------------------------
> 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
> Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
> lists.sourceforge.net
> The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
>
>
>
> ------------------------------------------------------------------------------
> 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
>
Chris Morley
2016-12-29 01:59:52 UTC
Permalink
Raw Message
Jim,


I did a quick basic stand alone test with your widget.

I like the modifications.


errors:

I did get an error when navigating past far left or far right on lathe offset pages.

I would guess this is because there are less columns showing.


audit:

When I entered a value the cursor moves down to the next tool rather then the next axis of the same tool.

I would think this is not what you wanted?


nitpic:


If I hold down cursor up (or down) to get to the first or last tool, it pauses at that tool, just as I would expect.

But when I release the button it then moves again which is slightly annoying.



Hope that helps
Chris M

________________________________
From: Jim Craig <***@windstream.net>
Sent: December 28, 2016 9:01 PM
To: EMC developers
Subject: Re: [Emc-developers] tooledit_widget modifications

Chris,

Thanks for the feedback. I did the fork method this time. I did my work
based on the tooledit_widget in the master branch so I think we are good
to go.

In general should I work in the master branch on my fork, or should I
make a separate branch in my fork based on the master branch?

Let me know what you think. I was thinking about adding in the escape
key to restore the pre-edited value to the cell. What do you think about
that?

Thanks again,

Jim

On 12/28/2016 1:24 AM, Chris Morley wrote:
> Hi Jim
>
>
> This sounds like a great improvement (I haven't actually tried it)
>
> The two ways of presenting one's work is forking or git patch.
>
> On small stuff I personally prefer patching (I don't use github much so am rusty) - but it doesn't really matter.
>
>
> As this is an upgrade (arguably) rather then a bug fix - it would usually go in master.
> tooledit in master may be different - I can't remember - if so you may need to adapt your patch for it.
>
> After that there is no real official way to guarantee inclusion or audit.
> Since Norbert and I probably are most familiar with and use this widget we probably are the best people
> to bug.
> I will try to test your widget soon.
>
> Chris M
>
> ________________________________
> From: Jim Craig <***@windstream.net>
> Sent: December 28, 2016 3:00 AM
> To: EMC developers
> Subject: Re: [Emc-developers] tooledit_widget modifications
>
> I committed the updated code to my fork of the project at
> https://github.com/LearningLinuxCNC/linuxcnc
[https://avatars2.githubusercontent.com/u/19329127?v=3&s=400]<https://github.com/LearningLinuxCNC/linuxcnc>

LearningLinuxCNC/linuxcnc<https://github.com/LearningLinuxCNC/linuxcnc>
github.com
linuxcnc - LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.



> [https://avatars2.githubusercontent.com/u/19329127?v=3&s=400]<https://github.com/LearningLinuxCNC/linuxcnc>
>
> LearningLinuxCNC/linuxcnc<https://github.com/LearningLinuxCNC/linuxcnc>
> github.com
> linuxcnc - LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.
>
>
>
>
> I put in a pull request to the linuxcnc project.
>
> The updated code allows for normal spreadsheet navigation and editing of
> the table. Tab and right arrow accepts the value in the current cell and
> moves to the next visible cell to the right. If the current active cell
> is the last cell on the row then it moves to the first visible cell on
> the row. Left arrow key works the same except in the left direction.
> Enter and down arrow accepts the value in the current cell and moves
> down one row in the same column. If on the last row then it will move to
> the first row in the table. The up arrow works the same except in the up
> direction.
>
> Let me know if I need to do anything different. Again first timer here
> so trying to figure out the correct process here.
>
> Thanks,
>
> Jim
>
> On 12/26/2016 5:53 PM, Jim Craig wrote:
>> I have the tooledit widget working as I like. This is the first time I
>> have wanted to publish my work on the project. What is the appropriate
>> method for me publishing the modified files?
>>
>> I have been reading the section on contributing to linuxcnc but I am a
>> bit confused at this point. Do I make my modifications in a fork of
>> the linuxcnc project under my username, or do I make the modifications
>> in a branch within the linuxcnc project?
>>
>> I have already forked linuxcnc to my username. I have cloned the fork
>> to my machine. Modified the files on my machine. Built a RIP linuxcnc
>> based on the modified code. Ran the runtest command on the new build
>> with no errors. Tested the functionality and It is working as I was
>> wanting.
>>
>> I believe the next step is to put my modified code to my linuxcnc fork
>> but I am not sure.
>>
>> Please let me know what the next step is.
>>
>> Also I think this modification could be published in the 2.7 branch as
>> well as master. Currently I have been working with a copy of master.
>> Should I publish the files to the 2.7 branch?
>>
>> Thanks,
>>
>> Jim
>>
>> On 12/22/2016 9:02 PM, Jim Craig wrote:
>>> I use gmoccapy on my milling machine. I really like that gui. Thanks
>>> Norbert!
>>>
>>> The one thing that I think is lacking is the way the tool table
>>> works. It is based on the tooledit_widget. It is a real pain to
>>> modify the tool table while in gmoccapy. To edit an entry you must
>>> check the line you want to edit, click on the cell that you want to
>>> edit change the value then you must press enter to accept the value.
>>> To edit another value you have to click on that cell, edit the value
>>> and press enter. Sorry cmorely, not bashing on your widget. I just
>>> want to make it better.
>>>
>>> This is not the way I normally edit a table. I use tab and enter and
>>> arrow keys to navigate a table. I have made some tweaks to the
>>> tooledit_widget.py and tooledit_gtk.glade to allow the tab key to
>>> accept the value in the current cell and advance to the next visible
>>> cell on the current row. I have also made all cells editable without
>>> having to have the checkbox in the first column checked. Also the
>>> Return key or the keypad enter key will accept the value in the
>>> current cell and progress to the same cell in the next row of the
>>> table. This makes navigating the table so much easier and faster.
>>>
>>> I can add in the arrow key movements as well. I have not done that
>>> yet but I can sure do it.
>>>
>>> I am trying to get my RIP install working but I am having issues per
>>> my other emails. Once I test it in a sim gmoccapy then I will be
>>> ready to put it on git if you all agree.
>>>
>>> Let me know if you have any questions or comments.
>>>
>>> Thanks,
>>>
>>> Jim
>>>
>
> ------------------------------------------------------------------------------
> 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
Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
lists.sourceforge.net
The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.



> Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
lists.sourceforge.net
The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.



> lists.sourceforge.net
> The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
>
>
>
> ------------------------------------------------------------------------------
> 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
Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
lists.sourceforge.net
The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.



>


------------------------------------------------------------------------------
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
Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
lists.sourceforge.net
The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
andy pugh
2016-12-29 11:13:49 UTC
Permalink
Raw Message
On 29 December 2016 at 01:59, Chris Morley <***@hotmail.com> wrote:
> When I entered a value the cursor moves down to the next tool rather then the next axis of the same tool.
> I would think this is not what you wanted?

That is the way spreadsheets often work. Tab to accept a value and
move right, enter to accept a value and move down.

--
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
Jim Craig
2016-12-29 13:42:43 UTC
Permalink
Raw Message
Chris,

See my replies below inline.

On 12/28/2016 7:59 PM, Chris Morley wrote:
> Jim,
>
>
> I did a quick basic stand alone test with your widget.
>
> I like the modifications.
>
>
> errors:
>
> I did get an error when navigating past far left or far right on lathe offset pages.
>
> I would guess this is because there are less columns showing.
I think I know how to fix the error. I am seeing it also. I did not
notice it before.
>
>
> audit:
>
> When I entered a value the cursor moves down to the next tool rather then the next axis of the same tool.
>
> I would think this is not what you wanted?
This is what I wanted. It is the way most spreadsheets work. If the
group does not like enter moving down then we can remove that
functionality or put it in as optional. Then the programmer using the
widget would have to decide to use it or handle the option in their main
application.
>
>
> nitpic:
>
>
> If I hold down cursor up (or down) to get to the first or last tool, it pauses at that tool, just as I would expect.
>
> But when I release the button it then moves again which is slightly annoying.
Well the function actually handles the key release event due to issues
with using the key press event occurring before a value is accepted. I
am not sure why it is pausing at the first or last tool. I will check on
that. Good test! I did not do the hold key test in my testing.

I think I could change it to use the key press event by adding in the
col_edited function and exiting the event handler sequence after the key
press event. I will give this a try today and report back on the results.
>
>
>
> Hope that helps
> Chris M
>
> ________________________________
> From: Jim Craig <***@windstream.net>
> Sent: December 28, 2016 9:01 PM
> To: EMC developers
> Subject: Re: [Emc-developers] tooledit_widget modifications
>
> Chris,
>
> Thanks for the feedback. I did the fork method this time. I did my work
> based on the tooledit_widget in the master branch so I think we are good
> to go.
>
> In general should I work in the master branch on my fork, or should I
> make a separate branch in my fork based on the master branch?
>
> Let me know what you think. I was thinking about adding in the escape
> key to restore the pre-edited value to the cell. What do you think about
> that?
>
> Thanks again,
>
> Jim
>
> On 12/28/2016 1:24 AM, Chris Morley wrote:
>> Hi Jim
>>
>>
>> This sounds like a great improvement (I haven't actually tried it)
>>
>> The two ways of presenting one's work is forking or git patch.
>>
>> On small stuff I personally prefer patching (I don't use github much so am rusty) - but it doesn't really matter.
>>
>>
>> As this is an upgrade (arguably) rather then a bug fix - it would usually go in master.
>> tooledit in master may be different - I can't remember - if so you may need to adapt your patch for it.
>>
>> After that there is no real official way to guarantee inclusion or audit.
>> Since Norbert and I probably are most familiar with and use this widget we probably are the best people
>> to bug.
>> I will try to test your widget soon.
>>
>> Chris M
>>
>> ________________________________
>> From: Jim Craig <***@windstream.net>
>> Sent: December 28, 2016 3:00 AM
>> To: EMC developers
>> Subject: Re: [Emc-developers] tooledit_widget modifications
>>
>> I committed the updated code to my fork of the project at
>> https://github.com/LearningLinuxCNC/linuxcnc
> [https://avatars2.githubusercontent.com/u/19329127?v=3&s=400]<https://github.com/LearningLinuxCNC/linuxcnc>
>
> LearningLinuxCNC/linuxcnc<https://github.com/LearningLinuxCNC/linuxcnc>
> github.com
> linuxcnc - LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.
>
>
>
>> [https://avatars2.githubusercontent.com/u/19329127?v=3&s=400]<https://github.com/LearningLinuxCNC/linuxcnc>
>>
>> LearningLinuxCNC/linuxcnc<https://github.com/LearningLinuxCNC/linuxcnc>
>> github.com
>> linuxcnc - LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.
>>
>>
>>
>>
>> I put in a pull request to the linuxcnc project.
>>
>> The updated code allows for normal spreadsheet navigation and editing of
>> the table. Tab and right arrow accepts the value in the current cell and
>> moves to the next visible cell to the right. If the current active cell
>> is the last cell on the row then it moves to the first visible cell on
>> the row. Left arrow key works the same except in the left direction.
>> Enter and down arrow accepts the value in the current cell and moves
>> down one row in the same column. If on the last row then it will move to
>> the first row in the table. The up arrow works the same except in the up
>> direction.
>>
>> Let me know if I need to do anything different. Again first timer here
>> so trying to figure out the correct process here.
>>
>> Thanks,
>>
>> Jim
>>
>> On 12/26/2016 5:53 PM, Jim Craig wrote:
>>> I have the tooledit widget working as I like. This is the first time I
>>> have wanted to publish my work on the project. What is the appropriate
>>> method for me publishing the modified files?
>>>
>>> I have been reading the section on contributing to linuxcnc but I am a
>>> bit confused at this point. Do I make my modifications in a fork of
>>> the linuxcnc project under my username, or do I make the modifications
>>> in a branch within the linuxcnc project?
>>>
>>> I have already forked linuxcnc to my username. I have cloned the fork
>>> to my machine. Modified the files on my machine. Built a RIP linuxcnc
>>> based on the modified code. Ran the runtest command on the new build
>>> with no errors. Tested the functionality and It is working as I was
>>> wanting.
>>>
>>> I believe the next step is to put my modified code to my linuxcnc fork
>>> but I am not sure.
>>>
>>> Please let me know what the next step is.
>>>
>>> Also I think this modification could be published in the 2.7 branch as
>>> well as master. Currently I have been working with a copy of master.
>>> Should I publish the files to the 2.7 branch?
>>>
>>> Thanks,
>>>
>>> Jim
>>>
>>> On 12/22/2016 9:02 PM, Jim Craig wrote:
>>>> I use gmoccapy on my milling machine. I really like that gui. Thanks
>>>> Norbert!
>>>>
>>>> The one thing that I think is lacking is the way the tool table
>>>> works. It is based on the tooledit_widget. It is a real pain to
>>>> modify the tool table while in gmoccapy. To edit an entry you must
>>>> check the line you want to edit, click on the cell that you want to
>>>> edit change the value then you must press enter to accept the value.
>>>> To edit another value you have to click on that cell, edit the value
>>>> and press enter. Sorry cmorely, not bashing on your widget. I just
>>>> want to make it better.
>>>>
>>>> This is not the way I normally edit a table. I use tab and enter and
>>>> arrow keys to navigate a table. I have made some tweaks to the
>>>> tooledit_widget.py and tooledit_gtk.glade to allow the tab key to
>>>> accept the value in the current cell and advance to the next visible
>>>> cell on the current row. I have also made all cells editable without
>>>> having to have the checkbox in the first column checked. Also the
>>>> Return key or the keypad enter key will accept the value in the
>>>> current cell and progress to the same cell in the next row of the
>>>> table. This makes navigating the table so much easier and faster.
>>>>
>>>> I can add in the arrow key movements as well. I have not done that
>>>> yet but I can sure do it.
>>>>
>>>> I am trying to get my RIP install working but I am having issues per
>>>> my other emails. Once I test it in a sim gmoccapy then I will be
>>>> ready to put it on git if you all agree.
>>>>
>>>> Let me know if you have any questions or comments.
>>>>
>>>> Thanks,
>>>>
>>>> Jim
>>>>
>> ------------------------------------------------------------------------------
>> 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
> Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
> lists.sourceforge.net
> The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
>
>
>
>> Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
> Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
> lists.sourceforge.net
> The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
>
>
>
>> lists.sourceforge.net
>> The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
> Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
> lists.sourceforge.net
> The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Emc-developers Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-developers>
> lists.sourceforge.net
> The Enhanced Machine Controller (EMC) is a CNC machine controller that runs on Linux and is available under the terms of the GNU General Public License.
>
>
>
> ------------------------------------------------------------------------------
> 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
>
EBo
2016-12-29 14:52:11 UTC
Permalink
Raw Message
I will also inline as below...

On Dec 29 2016 6:42 AM, Jim Craig wrote:
>
> See my replies below inline.
>
> On 12/28/2016 7:59 PM, Chris Morley wrote:
>> ...
>>
>> When I entered a value the cursor moves down to the next tool rather
>> then the next axis of the same tool.
>>
>> I would think this is not what you wanted?
>
> This is what I wanted. It is the way most spreadsheets work. If the
> group does not like enter moving down then we can remove that
> functionality or put it in as optional. Then the programmer using the
> widget would have to decide to use it or handle the option in their
> main
> application.

Would it be reasonable to set up a key/functionality map? I am not
sure it would be worth it, but I can see places where we might want to
map a different key to a function or possibly map a macro.

>> If I hold down cursor up (or down) to get to the first or last tool,
>> it pauses at that tool, just as I would expect.
>>
>> But when I release the button it then moves again which is slightly
>> annoying.
>
> Well the function actually handles the key release event due to
> issues
> with using the key press event occurring before a value is accepted.
> I
> am not sure why it is pausing at the first or last tool. I will check
> on
> that. Good test! I did not do the hold key test in my testing.

Is there any way to either set up an automated test suite or possibly
just a list of these tests? As a note, I *know* that automated GUI
testing is difficult (pre-Y2K I worked for a company that did exactly
this). There are some open source testers that might work
<https://en.wikipedia.org/wiki/Comparison_of_GUI_testing_tools>, but I
have absolutely no experiences with any of them.

EBo --
Jim Craig
2016-12-29 15:14:36 UTC
Permalink
Raw Message
replies are Inline below.

On 12/29/2016 8:52 AM, EBo wrote:
> I will also inline as below...
>
> On Dec 29 2016 6:42 AM, Jim Craig wrote:
>> See my replies below inline.
>>
>> On 12/28/2016 7:59 PM, Chris Morley wrote:
>>> ...
>>>
>>> When I entered a value the cursor moves down to the next tool rather
>>> then the next axis of the same tool.
>>>
>>> I would think this is not what you wanted?
>> This is what I wanted. It is the way most spreadsheets work. If the
>> group does not like enter moving down then we can remove that
>> functionality or put it in as optional. Then the programmer using the
>> widget would have to decide to use it or handle the option in their
>> main
>> application.
> Would it be reasonable to set up a key/functionality map? I am not
> sure it would be worth it, but I can see places where we might want to
> map a different key to a function or possibly map a macro.
I am not sure about this. I am sure it is possible but would it be worth it?
>
>>> If I hold down cursor up (or down) to get to the first or last tool,
>>> it pauses at that tool, just as I would expect.
>>>
>>> But when I release the button it then moves again which is slightly
>>> annoying.
>> Well the function actually handles the key release event due to
>> issues
>> with using the key press event occurring before a value is accepted.
>> I
>> am not sure why it is pausing at the first or last tool. I will check
>> on
>> that. Good test! I did not do the hold key test in my testing.
> Is there any way to either set up an automated test suite or possibly
> just a list of these tests? As a note, I *know* that automated GUI
> testing is difficult (pre-Y2K I worked for a company that did exactly
> this). There are some open source testers that might work
> <https://en.wikipedia.org/wiki/Comparison_of_GUI_testing_tools>, but I
> have absolutely no experiences with any of them.
I will look into this, but as with you I have no experience with these.

Thanks,

Jim
Niemand Sonst
2016-12-29 15:38:23 UTC
Permalink
Raw Message
Hallo Jim,

first I would say thanks for your work, I am compiling at the moment to
test from my side.
I checked the code and I would like to recommend:

Is it possible to get the code of:

onTreeNavigateKeyPress

in a own module? This way we would be able to use the same code also for
the offsetwidget and may be future widgets using a treeview.

I will report as soon as my testing ends.

Norbert

Am 29.12.2016 um 16:14 schrieb Jim Craig:
> replies are Inline below.
>
> On 12/29/2016 8:52 AM, EBo wrote:
>> I will also inline as below...
>>
>> On Dec 29 2016 6:42 AM, Jim Craig wrote:
>>> See my replies below inline.
>>>
>>> On 12/28/2016 7:59 PM, Chris Morley wrote:
>>>> ...
>>>>
>>>> When I entered a value the cursor moves down to the next tool rather
>>>> then the next axis of the same tool.
>>>>
>>>> I would think this is not what you wanted?
>>> This is what I wanted. It is the way most spreadsheets work. If the
>>> group does not like enter moving down then we can remove that
>>> functionality or put it in as optional. Then the programmer using the
>>> widget would have to decide to use it or handle the option in their
>>> main
>>> application.
>> Would it be reasonable to set up a key/functionality map? I am not
>> sure it would be worth it, but I can see places where we might want to
>> map a different key to a function or possibly map a macro.
> I am not sure about this. I am sure it is possible but would it be worth it?
>>>> If I hold down cursor up (or down) to get to the first or last tool,
>>>> it pauses at that tool, just as I would expect.
>>>>
>>>> But when I release the button it then moves again which is slightly
>>>> annoying.
>>> Well the function actually handles the key release event due to
>>> issues
>>> with using the key press event occurring before a value is accepted.
>>> I
>>> am not sure why it is pausing at the first or last tool. I will check
>>> on
>>> that. Good test! I did not do the hold key test in my testing.
>> Is there any way to either set up an automated test suite or possibly
>> just a list of these tests? As a note, I *know* that automated GUI
>> testing is difficult (pre-Y2K I worked for a company that did exactly
>> this). There are some open source testers that might work
>> <https://en.wikipedia.org/wiki/Comparison_of_GUI_testing_tools>, but I
>> have absolutely no experiences with any of them.
> I will look into this, but as with you I have no experience with these.
>
> Thanks,
>
> Jim
>
> ------------------------------------------------------------------------------
> 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
>
Jim Craig
2016-12-30 14:19:18 UTC
Permalink
Raw Message
On 12/29/2016 9:38 AM, Niemand Sonst wrote:
> Hallo Jim,
>
> first I would say thanks for your work, I am compiling at the moment to
> test from my side.
> I checked the code and I would like to recommend:
>
> Is it possible to get the code of:
>
> onTreeNavigateKeyPress
>
> in a own module? This way we would be able to use the same code also for
> the offsetwidget and may be future widgets using a treeview.
>
Norbert,

I am not sure that it is possible to put this in it's own module. It
depends on a specific function for the tooledit widget to accept the
values in the table to a specific format. I will finish making this
function the way everyone likes then I will look at pulling it out into
it's own module.

Thanks,

Jim
Chris Morley
2016-12-30 15:09:43 UTC
Permalink
Raw Message
It'S own module seems alot of work for little gain. It's about 10 lines of code or so. It can be copy and pasted into whatever program needs it. Changing the camel case name to not would suit the surrounding code ( nitpicking )
Chris M

----- Reply message -----
From: "Jim Craig" <***@windstream.net>
To: "EMC developers" <emc-***@lists.sourceforge.net>
Subject: [Emc-developers] tooledit_widget modifications
Date: Fri, Dec 30, 2016 6:22 AM



On 12/29/2016 9:38 AM, Niemand Sonst wrote:
> Hallo Jim,
>
> first I would say thanks for your work, I am compiling at the moment to
> test from my side.
> I checked the code and I would like to recommend:
>
> Is it possible to get the code of:
>
> onTreeNavigateKeyPress
>
> in a own module? This way we would be able to use the same code also for
> the offsetwidget and may be future widgets using a treeview.
>
Norbert,

I am not sure that it is possible to put this in it's own module. It
depends on a specific function for the tooledit widget to accept the
values in the table to a specific format. I will finish making this
function the way everyone likes then I will look at pulling it out into
it's own module.

Thanks,

Jim

------------------------------------------------------------------------------
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
Niemand Sonst
2016-12-30 17:15:47 UTC
Permalink
Raw Message
Hallo Chris,

it is not the amount of code, it is the maintenance of such.

If you use the code in 3 differnet files and you change only one line,
you will have to edit three files to get the same behavior.
IMHO not using code twice is the cleaner style.

Norbert

Am 30.12.2016 um 16:09 schrieb Chris Morley:
> It'S own module seems alot of work for little gain. It's about 10 lines of code or so. It can be copy and pasted into whatever program needs it. Changing the camel case name to not would suit the surrounding code ( nitpicking )
> Chris M
>
> ----- Reply message -----
> From: "Jim Craig" <***@windstream.net>
> To: "EMC developers" <emc-***@lists.sourceforge.net>
> Subject: [Emc-developers] tooledit_widget modifications
> Date: Fri, Dec 30, 2016 6:22 AM
>
>
>
> On 12/29/2016 9:38 AM, Niemand Sonst wrote:
>> Hallo Jim,
>>
>> first I would say thanks for your work, I am compiling at the moment to
>> test from my side.
>> I checked the code and I would like to recommend:
>>
>> Is it possible to get the code of:
>>
>> onTreeNavigateKeyPress
>>
>> in a own module? This way we would be able to use the same code also for
>> the offsetwidget and may be future widgets using a treeview.
>>
> Norbert,
>
> I am not sure that it is possible to put this in it's own module. It
> depends on a specific function for the tooledit widget to accept the
> values in the table to a specific format. I will finish making this
> function the way everyone likes then I will look at pulling it out into
> it's own module.
>
> Thanks,
>
> Jim
>
> ------------------------------------------------------------------------------
> 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
>
> ------------------------------------------------------------------------------
> 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
>
Niemand Sonst
2016-12-29 16:04:32 UTC
Permalink
Raw Message
Hallo Jim,

i just tested a little bit inside of gmoccapy:

- I miss the ESC button, otherwise a typing is not re-doable
- If you are already modifying the widget, would you be able to erase
the select column and make the marked line the active tool?
- I changed line 232 to be
self.toolfile = os.path.expanduser(filename)
and line 661 to be
tooledit.set_filename("~/linuxcnc/configs/sim.gmoccapy/tool.tbl")
- just click once in one line to highlight that line, then press tab
several times, do you see the order? The first cell getting editable is
the cell right from the click ;-) Is this the way it should be? If you
click twice, it works as expected.
- click once in a row, than press left, you will get a attribute error
(gmoccapy with popup, stand allow only on the terminal)
- once you are editing cells, it is not possible to get out of the edit
mode (one cell is in edit mode) without clicking on a new line, IMHO the
ESC Key should help here.

I do like the new behavior !! It is great!!

IMHO that is not only a new feature, it also improve handling a lot, so
it should go to 2.7 and master!!

Norbert
EBo
2016-12-29 16:38:18 UTC
Permalink
Raw Message
On Dec 29 2016 8:14 AM, Jim Craig wrote:
> replies are Inline below.
>
> On 12/29/2016 8:52 AM, EBo wrote:
>> I will also inline as below...
>>
>> On Dec 29 2016 6:42 AM, Jim Craig wrote:
>>> See my replies below inline.
>>>
>>> On 12/28/2016 7:59 PM, Chris Morley wrote:
>>>> ...
>>>>
>>>> When I entered a value the cursor moves down to the next tool
>>>> rather
>>>> then the next axis of the same tool.
>>>>
>>>> I would think this is not what you wanted?
>>> This is what I wanted. It is the way most spreadsheets work. If the
>>> group does not like enter moving down then we can remove that
>>> functionality or put it in as optional. Then the programmer using
>>> the
>>> widget would have to decide to use it or handle the option in their
>>> main application.
>> Would it be reasonable to set up a key/functionality map? I am not
>> sure it would be worth it, but I can see places where we might want
>> to
>> map a different key to a function or possibly map a macro.
>
> I am not sure about this. I am sure it is possible but would it be
> worth it?

Agreed. There may be some other code around to template this.
Unfortunately I am away from home on an emergency and do not have ready
access to my LinuxCNC systems.

>>>> If I hold down cursor up (or down) to get to the first or last
>>>> tool,
>>>> it pauses at that tool, just as I would expect.
>>>>
>>>> But when I release the button it then moves again which is
>>>> slightly
>>>> annoying.
>>> Well the function actually handles the key release event due to
>>> issues
>>> with using the key press event occurring before a value is
>>> accepted.
>>> I
>>> am not sure why it is pausing at the first or last tool. I will
>>> check
>>> on
>>> that. Good test! I did not do the hold key test in my testing.
>> Is there any way to either set up an automated test suite or
>> possibly
>> just a list of these tests? As a note, I *know* that automated GUI
>> testing is difficult (pre-Y2K I worked for a company that did
>> exactly
>> this). There are some open source testers that might work
>> <https://en.wikipedia.org/wiki/Comparison_of_GUI_testing_tools>, but
>> I
>> have absolutely no experiences with any of them.
>
> I will look into this, but as with you I have no experience with
> these.

Understand. Since this is mostly a GUI interface, if you can then just
add a file in with the source some place on a test/expect procedure then
we can replicate by hand if/when needed.

EBo --
Jim Craig
2016-12-29 15:09:49 UTC
Permalink
Raw Message
On 12/28/2016 7:59 PM, Chris Morley wrote:
>> errors:
>>
>> I did get an error when navigating past far left or far right on lathe offset pages.
>>
>> I would guess this is because there are less columns showing.
>
I was able to get this error fixed. It is on my fork with the latest commit.

The issue is that the first column is not editable in the lathe tool
offset page. I am not sure if this is the desired functionality or not
so I left it alone. If you want me to change it so the first column is
editable I can do that. This brought up the issue of editable cells. In
general it should not be an issue but the code now skips cells that are
not editable.

I will work on the other issues later.
Chris Morley
2016-12-30 02:16:59 UTC
Permalink
Raw Message
> audit:
>
> When I entered a value the cursor moves down to the next tool rather then the next axis of the same tool.
>
> I would think this is not what you wanted?
This is what I wanted. It is the way most spreadsheets work. If the
group does not like enter moving down then we can remove that
functionality or put it in as optional. Then the programmer using the
widget would have to decide to use it or handle the option in their main
application.
>

While it may be intuitive for spread sheets it doesn't make logical sense to me for tools.
When I edit/add a tool I would generally want to edit all the axes on that one tool.
If it could be user selectable option that would be nice.

>
> nitpic:
>
>
> If I hold down cursor up (or down) to get to the first or last tool, it pauses at that tool, just as I would expect.
>
> But when I release the button it then moves again which is slightly annoying.
Well the function actually handles the key release event due to issues
with using the key press event occurring before a value is accepted. I
am not sure why it is pausing at the first or last tool. I will check on
that. Good test! I did not do the hold key test in my testing.

I think I could change it to use the key press event by adding in the
col_edited function and exiting the event handler sequence after the key
press event. I will give this a try today and report back on the results.
>

I like that it pauses at the top and bottom - a happy accident :)
Jim Craig
2016-12-30 14:42:25 UTC
Permalink
Raw Message
On 12/29/2016 8:16 PM, Chris Morley wrote:
>
>
>
>> audit:
>>
>> When I entered a value the cursor moves down to the next tool rather then the next axis of the same tool.
>>
>> I would think this is not what you wanted?
> This is what I wanted. It is the way most spreadsheets work. If the
> group does not like enter moving down then we can remove that
> functionality or put it in as optional. Then the programmer using the
> widget would have to decide to use it or handle the option in their main
> application.
> While it may be intuitive for spread sheets it doesn't make logical sense to me for tools.
> When I edit/add a tool I would generally want to edit all the axes on that one tool.
> If it could be user selectable option that would be nice.
What would you like the enter key to do? Just accept the value and not
move the active cell? Accept the value and move to the right in the
table? Any of the above options?
>
>> nitpic:
>>
>>
>> If I hold down cursor up (or down) to get to the first or last tool, it pauses at that tool, just as I would expect.
>>
>> But when I release the button it then moves again which is slightly annoying.
> Well the function actually handles the key release event due to issues
> with using the key press event occurring before a value is accepted. I
> am not sure why it is pausing at the first or last tool. I will check on
> that. Good test! I did not do the hold key test in my testing.
>
> I think I could change it to use the key press event by adding in the
> col_edited function and exiting the event handler sequence after the key
> press event. I will give this a try today and report back on the results.
> I like that it pauses at the top and bottom - a happy accident :)
I will see what I can do to preserve that and improve some other quirks
that have been noticed. I think I need to be working with the key press
event instead of the key release event.
>
>
>
> ------------------------------------------------------------------------------
> 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
>
Chris Morley
2016-12-30 15:12:48 UTC
Permalink
Raw Message
Entering a value with return and it auto moving to the right seems intuitive.
I'm glad you are doing this work-I never found the time and ambition to go back and do it :)
Thanks
Chris M

----- Reply message -----
From: "Jim Craig" <***@windstream.net>
To: "EMC developers" <emc-***@lists.sourceforge.net>
Subject: [Emc-developers] tooledit_widget modifications
Date: Fri, Dec 30, 2016 6:46 AM



On 12/29/2016 8:16 PM, Chris Morley wrote:
>
>
>
>> audit:
>>
>> When I entered a value the cursor moves down to the next tool rather then the next axis of the same tool.
>>
>> I would think this is not what you wanted?
> This is what I wanted. It is the way most spreadsheets work. If the
> group does not like enter moving down then we can remove that
> functionality or put it in as optional. Then the programmer using the
> widget would have to decide to use it or handle the option in their main
> application.
> While it may be intuitive for spread sheets it doesn't make logical sense to me for tools.
> When I edit/add a tool I would generally want to edit all the axes on that one tool.
> If it could be user selectable option that would be nice.
What would you like the enter key to do? Just accept the value and not
move the active cell? Accept the value and move to the right in the
table? Any of the above options?
>
>> nitpic:
>>
>>
>> If I hold down cursor up (or down) to get to the first or last tool, it pauses at that tool, just as I would expect.
>>
>> But when I release the button it then moves again which is slightly annoying.
> Well the function actually handles the key release event due to issues
> with using the key press event occurring before a value is accepted. I
> am not sure why it is pausing at the first or last tool. I will check on
> that. Good test! I did not do the hold key test in my testing.
>
> I think I could change it to use the key press event by adding in the
> col_edited function and exiting the event handler sequence after the key
> press event. I will give this a try today and report back on the results.
> I like that it pauses at the top and bottom - a happy accident :)
I will see what I can do to preserve that and improve some other quirks
that have been noticed. I think I need to be working with the key press
event instead of the key release event.
>
>
>
> ------------------------------------------------------------------------------
> 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
>


------------------------------------------------------------------------------
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
Niemand Sonst
2017-02-19 12:47:14 UTC
Permalink
Raw Message
Hallo @all,

with a previous merge of 2.7 into master I got some smaller issues with
gmoccapy, that is why I want to ask all of you, not to merge gmoccapy
2.7 related code to master!

The differences under the hood are not only minor stuff. The releases of
gmoccapy 1.XX and 2.XX are not mergeable any more.
I will push only bugfixes to 2.7 and all new stuff to master.

so if you merge 2.7 to master, please exclude gmoccapy from the merge. I
think I can maintain my GladeVCP code to fit both master and 2.7

Other option would be maintain gmoccapy 1.XX also in master and rename
gmoccapy2.XX to something else, but that might disturb actual users.
(I have count about 400 users, from beginning developing gmoccapy till
today)

Please give me a comment on this.

Norbert
Jeff Epler
2017-02-21 15:42:53 UTC
Permalink
Raw Message
Hi.

I understand what you are asking for, and I think your motivation is
good. But since your suggestion impacts all developers who are fixing
bugs, we need to have a dialog about it and find a solution that serves

The crux of the issue I see is that "git merge branch-A" when on
branch-B always merges *ALL* commits that are on branch-A and not yet on
branch-B, and our workflow is to merge 2.7 to master "from time to time"
in order to get all the bugfixes and minor enhancements in the
development version.

This workflow seems to function well for most parts of LinuxCNC, and I
would like to preserve it. Other workflows, such as using cherry-pick
to make similar changes in 2.7 and master, put extra responsibility on
*all* developers who make changes to 2.7, and increase the risk that a
change that SHOULD have been made in 2.7 and master is made only in
master.

Instead, I'd rather search for some guidelines and strategies that will
rarely impact developers who are fixing bugs in linuxcnc that are not
related to gmoccapy. However, I think it's inevitable that this will
impose some extra duties on developers pushing fixes to gmoccapy bugs in
2.7.

Basically, I propose the following workflow for fixing gmoccapy bugs
differently in 2.7 and master:
* Make the appropriate change in 2.7, test and push
* Switch to master branch
* Merge 2.7 to master with but don't commit. Typical commandline:
git merge --no-commit origin/2.7
* Discard gmoccapy changes, regardless of whether they are conflicts.
Typical commandline:
git checkout --ours -- \
configs/sim/gmoccapy \
docs/src/gui/gmoccapy* \
docs/src/gui/images/gmoccapy* \
share/gmoccapy \
src/emc/usr_intf/gmoccapy \
src/po/gmoccapy
[note use of the shell line-continuation character "\" to avoid long
lines in this e-mail]
* test, commit, and push master branch
* If applicable, make the gmoccapy appropriate change/bugfix for master
branch and push that

For developers not working on gmoccapy, the only change in the workflow
is that, in case a merge conflict is seen and it names a gmoccapy file,
to contact Norbert (or any fellow gmoccapy developers he cares to
designate) instead of trying to resolve any merge conflicts themselves.

There are probably other ways to accomplish this goal; the workflow for
fixing gmoccapy bugs in 2.7 that I outline above is just the first
method I thought of. Let's continue this dialogue and find the solution
that seems to have the least complexity.

Jeff
PS renaming files won't help, because in at least some cases git is
smart enough to automatically find the renamed file and apply the change
to it (this can be disabled by 'git merge -Xno-renames' but I wouldn't
want to require this, since it means we also couldn't do "good renames"
but could only use renaming as a way to break automatic merging)
Niemand Sonst
2017-02-22 17:08:36 UTC
Permalink
Raw Message
Hallo,

I do agree, that we should not change the way of merging branches. I
just would like to be informed if there are any merge conflicts
regarding gmoccapy, as I can surely see easier than others how to fix them.

Thanks for your comprehensiveness.

Norbert

Am 21.02.2017 um 16:42 schrieb Jeff Epler:
> Hi.
>
> I understand what you are asking for, and I think your motivation is
> good. But since your suggestion impacts all developers who are fixing
> bugs, we need to have a dialog about it and find a solution that serves
>
> The crux of the issue I see is that "git merge branch-A" when on
> branch-B always merges *ALL* commits that are on branch-A and not yet on
> branch-B, and our workflow is to merge 2.7 to master "from time to time"
> in order to get all the bugfixes and minor enhancements in the
> development version.
>
> This workflow seems to function well for most parts of LinuxCNC, and I
> would like to preserve it. Other workflows, such as using cherry-pick
> to make similar changes in 2.7 and master, put extra responsibility on
> *all* developers who make changes to 2.7, and increase the risk that a
> change that SHOULD have been made in 2.7 and master is made only in
> master.
>
> Instead, I'd rather search for some guidelines and strategies that will
> rarely impact developers who are fixing bugs in linuxcnc that are not
> related to gmoccapy. However, I think it's inevitable that this will
> impose some extra duties on developers pushing fixes to gmoccapy bugs in
> 2.7.
>
> Basically, I propose the following workflow for fixing gmoccapy bugs
> differently in 2.7 and master:
> * Make the appropriate change in 2.7, test and push
> * Switch to master branch
> * Merge 2.7 to master with but don't commit. Typical commandline:
> git merge --no-commit origin/2.7
> * Discard gmoccapy changes, regardless of whether they are conflicts.
> Typical commandline:
> git checkout --ours -- \
> configs/sim/gmoccapy \
> docs/src/gui/gmoccapy* \
> docs/src/gui/images/gmoccapy* \
> share/gmoccapy \
> src/emc/usr_intf/gmoccapy \
> src/po/gmoccapy
> [note use of the shell line-continuation character "\" to avoid long
> lines in this e-mail]
> * test, commit, and push master branch
> * If applicable, make the gmoccapy appropriate change/bugfix for master
> branch and push that
>
> For developers not working on gmoccapy, the only change in the workflow
> is that, in case a merge conflict is seen and it names a gmoccapy file,
> to contact Norbert (or any fellow gmoccapy developers he cares to
> designate) instead of trying to resolve any merge conflicts themselves.
>
> There are probably other ways to accomplish this goal; the workflow for
> fixing gmoccapy bugs in 2.7 that I outline above is just the first
> method I thought of. Let's continue this dialogue and find the solution
> that seems to have the least complexity.
>
> Jeff
> PS renaming files won't help, because in at least some cases git is
> smart enough to automatically find the renamed file and apply the change
> to it (this can be disabled by 'git merge -Xno-renames' but I wouldn't
> want to require this, since it means we also couldn't do "good renames"
> but could only use renaming as a way to break automatic merging)
>
> ------------------------------------------------------------------------------
> 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
>
Chris Morley
2017-02-22 17:32:43 UTC
Permalink
Raw Message
I have the same problem with pncconf.The best seems to be to merge the branches immediately after pushing.
If you merge whether you did work in master or 2.7 then anyone merging after you should have little problem.
Of course hopefully there are no other difficult conflicts to deal with. Usually it's fairly straight forward.

Chris M

----- Reply message -----
From: "Niemand Sonst" <***@web.de>
To: "emc-***@lists.sourceforge.net" <emc-***@lists.sourceforge.net>
Subject: [Emc-developers] gmoccapy - differences between 2.7 and master
Date: Wed, Feb 22, 2017 9:10 AM



Hallo,

I do agree, that we should not change the way of merging branches. I
just would like to be informed if there are any merge conflicts
regarding gmoccapy, as I can surely see easier than others how to fix them.

Thanks for your comprehensiveness.

Norbert

Am 21.02.2017 um 16:42 schrieb Jeff Epler:
> Hi.
>
> I understand what you are asking for, and I think your motivation is
> good. But since your suggestion impacts all developers who are fixing
> bugs, we need to have a dialog about it and find a solution that serves
>
> The crux of the issue I see is that "git merge branch-A" when on
> branch-B always merges *ALL* commits that are on branch-A and not yet on
> branch-B, and our workflow is to merge 2.7 to master "from time to time"
> in order to get all the bugfixes and minor enhancements in the
> development version.
>
> This workflow seems to function well for most parts of LinuxCNC, and I
> would like to preserve it. Other workflows, such as using cherry-pick
> to make similar changes in 2.7 and master, put extra responsibility on
> *all* developers who make changes to 2.7, and increase the risk that a
> change that SHOULD have been made in 2.7 and master is made only in
> master.
>
> Instead, I'd rather search for some guidelines and strategies that will
> rarely impact developers who are fixing bugs in linuxcnc that are not
> related to gmoccapy. However, I think it's inevitable that this will
> impose some extra duties on developers pushing fixes to gmoccapy bugs in
> 2.7.
>
> Basically, I propose the following workflow for fixing gmoccapy bugs
> differently in 2.7 and master:
> * Make the appropriate change in 2.7, test and push
> * Switch to master branch
> * Merge 2.7 to master with but don't commit. Typical commandline:
> git merge --no-commit origin/2.7
> * Discard gmoccapy changes, regardless of whether they are conflicts.
> Typical commandline:
> git checkout --ours -- \
> configs/sim/gmoccapy \
> docs/src/gui/gmoccapy* \
> docs/src/gui/images/gmoccapy* \
> share/gmoccapy \
> src/emc/usr_intf/gmoccapy \
> src/po/gmoccapy
> [note use of the shell line-continuation character "\" to avoid long
> lines in this e-mail]
> * test, commit, and push master branch
> * If applicable, make the gmoccapy appropriate change/bugfix for master
> branch and push that
>
> For developers not working on gmoccapy, the only change in the workflow
> is that, in case a merge conflict is seen and it names a gmoccapy file,
> to contact Norbert (or any fellow gmoccapy developers he cares to
> designate) instead of trying to resolve any merge conflicts themselves.
>
> There are probably other ways to accomplish this goal; the workflow for
> fixing gmoccapy bugs in 2.7 that I outline above is just the first
> method I thought of. Let's continue this dialogue and find the solution
> that seems to have the least complexity.
>
> Jeff
> PS renaming files won't help, because in at least some cases git is
> smart enough to automatically find the renamed file and apply the change
> to it (this can be disabled by 'git merge -Xno-renames' but I wouldn't
> want to require this, since it means we also couldn't do "good renames"
> but could only use renaming as a way to break automatic merging)
>
> ------------------------------------------------------------------------------
> 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
>


------------------------------------------------------------------------------
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
Loading...