New Interface

[vlachoudis]

When I started writing bCNC I wanted to have something quickly done that fills my needs as GUI. I didn't want to develop a GUI just to work on it, but rather to use it as tool. So some decisions, e.g. the menus, functionality layout etc were quickly done without much thought. Now since several persons are actively using it, I was seriously thinking of rewriting the interface possibly in a better way. The issues I wanted to address/fix are:

• Split the functionality from the gui.
• Integrate in a nice way the function/macro features
• A lot of functionality was duplicated in the menu, toolbar, buttons and shortcuts
• Menus are "hard" to use hiding some of the functionality
• Easier visibility of the various features
• Easier interface and more logically organized
• Customizable to some extend (fonts, shortcuts, favorite actions...)
• better icons :) Constraints:
• I want to stick with tkinter which a bit old as toolkit not offering the powerful features of other tks, but very simple to use :)
• I don't want to spend too much time on developing it.
• Keep it simple for RPi

If you want to give a look, I have one very very primitive version in the eval branch. You can start the program using the bCNC2.py. It resembles a bit the ribbon style of MS office. Before investing more time on that I would like to hear from you your opinion pros/cons ideas. I have some interaction with @Effer and @chamnit You can even sketch something and send it over.

My new approach

or @Effer proposal

Vasilis

[chamnit]

@vlachoudis : I think the very first thing to do is define what the minimum resolution this new interface will require. Is it 1280x768? 1024x768? 1400x1050? 1080p? There are a myriad of options, but these are typically constrained by the lowest common denominator. Since bCNC runs extremely well on the slowest of machines, I think this should be a large part of the final decision on this matter.

For me, it's either 1024x768 or 1280x768.

[HomineLudens]

@chamnit: resolution is a good starting point. I agree it should be as low as 1024x768. I'd like to keep in mind also the preferred monitor ratio (4:3 or 16:9) to choose where put most of the buttons (Top or Side).

But the good @vlachoudis is using well the resizable capabilities of tkinter, all GUI fits well in a wide range of resolutions. Only not automatically resizable seems the fonts.

I believe the most consuming widget , in term of cpu power, is the main canvas. Adding an option to hide it, or reducing/optimize the refresh time could allow bCNC to run on any hardware.

Main concern about Tkinter (that I've started to appreciate because present in most of python installations) is the missing of hardware accelerated graphics. Especially in Rpi it could mean a high boost on performance.

[chamnit]

@Effer : Resizing capabilities lead to some questions about how things should resize and even if there should be separate large and small resolution versions. For example, a small resolution wouldn't be able to do your layout proposal, but a large or wide screen could. This is when modern GUI frameworks are really helpful, as scaling and modularization is a bit easier to deal with issues like this.

The only problem with 1024x768 is that it's not that much space. Most Grbl GUIs I've seen deal with this problem by creating a tabbed window, like @vlachoudis has proposed. Each tab shows only the GUI elements that are needed for each tab. For example, the canvas (visualizer) isn't needed all of the time, nor is the run state of Grbl. The workspace tab can be expanded to encompass the entire window so you have more flexibility in how you set the work coordinate offset data or probing tools.

Hardware accelerated graphics would be nice, but I've seen a lot of issues with other GUIs where compatibility is broken for one reason or another on different machines. The best implementations of visualizers I've seen are through web browsers and written in JavaScript. They decouple OS-specific problems with universally supported browser frameworks (and have access to modern GUI frameworks). This model works really well. There has been some offline talk about using bCNC's powerful backend and virtual pendant approach to serve a browser-based solution. Here I think we can invest in graphics.

For bCNC and tkinter, I'd just like to see a simple user-friendly interface. Nothing overly complex. Anyhow, I'll think about what is really required per tabbed window and hopefully sketch something up.

[vlachoudis]

@chamnit My aim is to go for the smallest resolution. The present version of the code has a limit of 690px on the vertical, is less constraint on horizontal. With the ribbon reorganization even though it takes more vertical space it frees also some horizontal space for buttons, as a consequence it requires 100px less on the vertical.

@Effer proposal with 3 columns is nice, oriented for wide screens 16:9. On old screens like my controlling laptop with 4:3 and a resolution 1024x768 would be a bit problematic.

@Effer also mentioned the same thing that some widgets are not necessary to be on all the time like the DRO, also the MDI takes too much space.

Thinking loudly, an option could be to have two columns (as it is now control panel + visualiser) and a ribbon/toolbar on top, however the content of each column to be chosen by the user. e.g. jog + wcs, or jog + terminal, or editor + visualizer, or jog+visualizer etc..., with the user selecting on which column to display the information. The only thing I fear is that providing too much freedom to the end user, will be more confusing than making things simpler.

@chamnit maybe it is just me, but how I am working I always want to have the visualizer on. I cannot jog or probe without seeing on the visualizer the location

[Scott216]

I don't use the visualizer very much. I mainly use it when I load new gcode to verify everything looks as it should.

[chamnit]

@vlachoudis : Great. So 1024x768 (690 vert for OS windows and bars) is sounding like the goal. While it can be expandable horizontally to wide 16:9 screens.

As for the visualizer, true you probably do need it for things like probing and jogging, but you don't necessarily need it for everything. Perhaps the two column idea is appropriate, and only allow one of the columns to have visualizer and editor only. Not sure though.

I agree though that too much configurability does lend to complexity. We may have to do the Apple thing and decide what and how users will interact with a rigid, limited interface. The tab pages idea lends to this type of simplification. Probing could be made a separate tab with a visualizer, while work coordinate offsets and other parameters can be another without it. Jogging can also be a separate tab. Although potentially annoying to flip between as tabs, jogging is realistically only used during job setup and sometimes after job completion. Never during a job.

One thing I love about Carbide3d's CarbideMotion Grbl GUI is that they simplify the fundamental tasks of how to run a machine. It's not full-featured as bCNC, so take this comment with a grain of salt. The first thing a user sees is two large buttons. Load a job or jog the machine. Click one. The jogging window is really simple and is design for you to determine part zero or where your job start location is. You can set work coordinates there. The load job simply loads the gcode file and runs it, while you have some minimal feed hold control. It shows you the run state, positions, running speed, and percent complete. That's it. IF needed, you can open a separate window that shows terminal output and another for MDI. I'm not saying that bCNC should be this simple, but it's an example that I find noise-free.

[WillAdams]

I believe that one could achieve decent configurability w/o unnecessary complexity, just by making things direct and interactive and providing obvious states and controls.

Lessee, we need the following information / sections:

• Machine state --- D.R.O., &c.
• Direct User controls --- jogging, &c.
• Workspaces
• Previewing
• Terminal
• Tools
• Editor

I think machine state should run across the top of the machine, and there should be a dividing bar which allows the user to determine the size of it --- allow things to re-arrange to a reasonable degree, if they don't fit, scale them down (or up) to fit the available space.

All the other things should have multiple states which allow varying degrees of interaction and would be arranged in a row, and the user would be able to determine the state for each area.

Hang on while I see what I can draw up.

[WillAdams]

Okay, obviously I'm a big fan of Carbide 3D's nifty diamond arrangement of the controls (did anyone do that before they did? Seems obvious...)

Anyway, pardon the mix of ASCII art and quickly drawn graphics. I guess in the collapsed state each pane could go down to just the icon.

[HomineLudens]

IMO there are three main conditions of use:

• Running a Job
• Edit a part program
• Configure bCNC

Each needs some widgets not used by the other (except the canvas used both for job and editing) . We could offers three tab to switch to one of these use. Then inside rearrange all the space in a more comfortable way and offer only related menu. Ribbons menu are nice but tends to steal a lot of free space. Sorry I can't sketch anything for a few days.

[vlachoudis]

@WillAdams thanks for the sketch. Your proposal is to have multiple columns which can be expanded/hidden from the user? It could offer any configuration the user wants, with the penalty of increasing clicks to enable and disable the panes. About the diamond buttons are not available in tkinter. All objects are rectangular, but could be done manually as drawings in a canvas.

I see some similarity between the proposal of @WillAdams and @Effer.

It is true that bCNC as it is right now, it is two programs in one, a sender and a basic g-code editor. That makes life complicated to have a common interface for both. One approach could be to hide the gui panels of one program from the other.

Maybe more important than the interface would be to invest as it is proposed by @chamnit and @onekk to minimize the widgets, without compromizing the functionality. e.g. once set the port, baud you don't need to see them on the all the time. Maybe other widgets could be minimized, machine coordinates? workspace set coordinates, probing, autoleveling. Providing less buttons with the same functionality.

[chamnit]

@vlachoudis : Perhaps creating a grid of available functionality cross-referenced with the type of task would be useful. For example, a g-code sending task would require file loading, runtime controls, real-time feedback, visualizer (maybe), etc. Another task, like file-editing, would populate this grid differently.

This could get messy before it gets simpler, which it kinda already has, but this would be a great investment in time and tell us quite a lot on how "form will follow function."

[WillAdams]

Yes, that’s exactly what I had in mind.

Agree that a grid of functionality and usages would be a useful thing — I’ll see what I can work up.

[HomineLudens]

So finally I've got some spare time to sketch up something. Pictures are 800x600 and some of the widgets are missing. The top buttons should bring to different work scenario and propose only related controls. I see lately the thread has been really quiet, any news @vlachoudis ?

[chamnit]

@Effer : That's a really nice layout proposal. Pretty close to what I had in mind as well.

@vlachoudis has been waiting on me to give some feedback with what to expect from Grbl going forward and things learned from researching the state of LinuxCNC, Mach3, other Grbl GUIs, and Haas. I sent him an outline of a proposal with general concepts and constructs just last week. Basically I concluded that there is no silver bullet. The best thing to do is make things as modular as you can, like a visualizer module or a editor module and attach module specific controls to each one. Each module may be placed anywhere on any tab. It's pretty much what you have done @Effer.

With a tab-based approach like this with modules, you would give great leeway for custom interfaces per user/machine-requirements, which can be drastically different. It's a lot of setup of work to do this, but if the framework is sound, this would also allow other users to create their own modules and begin to contribute to the bCNC project.

[HomineLudens]

@chamnit : even proposing that simple restyle I found many different approach to best fit different work needs. I agree that the best solution is more a fact of progressive tuning over a nice set of user control, and that probably will take lots of time.

Happy to hear that works are still in progress and that we can expect a major update. I was little worried for this unusual (2 weeks) delay over usually frequently updates by @vlachoudis .

I'm waiting for the new plugin system to be ready and continue to contribute to bCNC

Good job everybody.

[vlachoudis]

Thanks @Effer, it looks nice and clean. I've tried over the past weeks to re-organize a bit the internal structure so to permit groups of buttons to be activated/deactivated for every tab, and to be up to the user to organize which groups he likes in which tabs.

However I didn't had much time to work on bCNC, due to heavy work load in the experiment, heat wave in Europe and political situation in my country.

[vlachoudis]

Its been a while I've be working on the new interface. Now I am happy to announce that the eval branch contains a version of the new bCNC which is "fully" operational. Apart from many changes in the interface, it brings many new features, based on your comments, code-requests.

Its been some time I am using only the new interface, and apart from a bit of confusion in the beginning, searching commands in a different place, honestly I find it more easy to use, to control the machine and edit the gcode than the previous version.

I would appreciate if you could test to find bug/problems and give me your comments before I push it on the main branch

Code:

• I've tried to make the code cleaner especially for the core, but due to multiple trials I think I ended up with a lot of dirty code :( on the interface side.
• Slowly I am splitting the functionality from the interface, to be possible to run the pendant without the Tkinter interface (if needed) #13
• Function evaluations #38
• Feed override (from @Effer ) #98
• User macro/plugin system. Python scripts written in the plugin directory can appear in the tools to directly manipulate or generate gcode (like the finger box and a primitive gear generator)
• overcuts in the profile generator
• user definable shortcuts #74
• fonts, colors user defined @onekk
• laser cutter option #93

Interface: I've stick with the ribbon and the two pages, including some ideas from your comments. The reason was that going to the editor or the tools needed a lot of buttons, and that would mean to introduce again a menu bar or find new locations for the various buttons.

The good thing is that the ribbon and the frames are fully customizable from the ini file, so anyone can configure it as he likes. There are a lot of modifications and improvements.

In brief some of the improvements changes:

• Status is a button and gives an interpretation of the grbl error message (it needs re-working to become nicer and show also the problematic line)
• WPos is editable to set directly the position (reducing number of input fields)
• @onekk addition for a separate z-scale, configurable if one sets a zstep in the ini file. By default is disabled.
• Probe contains the tools for a simple probe, center probing with a ring and autolevel.
• The autolevel can display a color map in X-Y, (ONLY if you have installed numpy and PIL). I will make it to work for the ISOx (in the future)
• Tools: Introduction of a macro plugin mechanism (see the gear/box)
• Various configuration now is located in the tools (to be moved in a separate page or in the File page)
• Editor I've added a few functions for gcode reorganization. I will introduce in a while a genetic algorithm for optimizing the order of cuts (minimizing rapid distance movements)
• Canvas have its own tool bar
• Icons needs some work :)

The size for the moment is always fixed to 800x600 just to check for small screens. Please copy/save your .bCNC ini file before using the new version

[vlachoudis]

Hi all. I wanted to report that the eval branch is quite advanced now and fully operational. The latest feature is "Manual Tool Change" (still experimental but works) I am trying to spot and correct as many problems as possible before pushing it on the master branch.

[vlachoudis]

Hi all.

I wanted to report that that the new interface is fully operational, and from now on is the default master.

The latest addition is "Manual Tool Change" works nicely. Yesterday I produced a PCB and I used the Manual Tool Change to create the various hole sizes, without a problem.

There are numerous additions and improvements which have to be documented in the Wiki page.

• Clicking on the Status of the machine gives an extended information and the last offending error line.
• 3D color map of the autoleveling
• Function evaluation
• Simpler WCS configuration
• Clicking on the WPos you can enter the new location manually (no need of extra fields)
• Feed override during the run
• User customization of the ribbon and left frame from the .bCNC file (look the bCNC.ini for the present configuration)
• Fonts/color user configuratble
• Plug-in mechanism (presently with the finger box and a simple spur gear generator)
• Improved profile operation with overcuts
• Ordering of gcode to minimize the rapid movements
• ...

It needs some extra work to finalize the split between interface and functionality (classes bCNC and Sender) to allow if someone wishes to run only the pendant without starting the interface.

And of course the location of buttons is my first try, since I've reworked the whole code now they can easily be moved in any frame/ribbon etc we need.

Vasilis

[mandrav]

Awesome work Vasili !!

[vlachoudis]

Thank you @mandrav.

[vlachoudis]

@onekk yes you can use eval functions anywhere in the user buttons, as well in the command line. For example I have as a user macro, something proposed by @1bigpig that scans around the margins of the gcode with rapid motions.

g0 x[xmin] y[ymin] g0 x[xmax] g0 y[ymax] g0 x[xmin] g0 y[ymin]

However the Tool change function now is inside bCNC. In the tab "Probe" click on "Tool" and you can setup how bCNC will treat the M6 (Tool change commands)

1. Send to Grbl as is
2. Ignore completly
3. Replace with a "tool change" macro which
   • Stops the spindle
   • Raises to the Change-Z height
   • Rapid move to Change X,Y
   • Wait until you change the tool with a feed hold
   • Click on resume (hardware or pause software button)
   • go to Probe X,Y
   • lower to Probe Z
   • perform a probe scanning from ProbeZ to ProbeZ - Distance
   • reset the 0 of the workspace to match the new tool (maybe I should set it to the offset)
   • and go back inverting the order -> ChangeZ -> ChangeX,Y and continue the gcode

The first time you need to perform a calibration cycle, so bCNC to find the height of the probe tester (plate or switch) vs the 0 of your surface You can also activate manually the tool change by clicking on the "Change" button

I have to write it on the Wiki :)

[mandrav]

Right when I was about to ask how tool change works :+1:

[vlachoudis]

Perfect timing. I forgot to mention that the Change, Probe locations (which are absolute machine coordinates) you can get them by jogging to the desired location and click the "get" button. The probez / distance should be selected such as to cover the range of all possible tools to use. In my device I've installed a tiny switch as a fixed probing (maybe a touch plate would be better, but I was lazy to plug unplug the cables on every tool).

[vlachoudis]

Hi all, there was a bug in the new interface, that was polluting the .bCNC ini file with duplicate terms in the [EndMill] section. If you have not used at all the EndMills database it is better to delete the whole section otherwise delete all terms starting with underscore _ (namely the coating., shape., type., material.).

[onekk]

Thanks, bCNC is improving very well, a little question is unanswered, how to do a calibration cycle?

I have done a little job about the probe function on the wiki, I have copied your answer and processed a little, if you complete the wiki page your time is better spent than to answer at my question here.

https://github.com/vlachoudis/bCNC/wiki/Tool-Change

Regards and Chapeau.

Carlo D. (onekk)

P.S. To make this page more readable I've deleted all my previous post, I think this is better to make this important Issue more readable in the key points.

[mandrav]

Vasili, is the old Control/Statistics functionality removed now? Or am I blind ;) It was nice to have a rough indication of the time needed to run a job.

[vlachoudis]

@onekk for the calibration cycle: First zero your z-axis with the current tool on your workpiece, and if you have set the change, probe location and probe distance, click on the "Calibrate", it will move the gantry to the change -> probe location and start a probe cycle. Once the probe is finished, the calibration field will be set, with the height of the probe plate/switch versus the 0 of your work piece.

[vlachoudis]

@mandrav it is still there in the "Editor" tab -> "Edit" group there is small "arrow down" on the word Edit. If you click it it will open a menu with less frequent tools, like the inkscape, stats etc.. Also in the "Order" there is a same button which optimizes the rapid movements on the selected blocks of gcode.

[mandrav]

Nice, thanks for the pointers!

[HomineLudens]

@vlachoudis it seems like the probe page doesn't save the sub-mode selected for the next start of bCNC. But this actually happen in the Tool page. Is this wanted?

[vlachoudis]

@Effer simply I forgot to save it :) I will do

[vlachoudis]

A recent change, as it was proposed by @chamnit and @Effer some time ago, if you unckeck the drawing of the rapid and slow paths, it doesn't scan the gcode, resulting in faster loading, of huge gcode files. However it will fail to report any statistics for the gcode like margins, total length, total time before running.

[Nandox7]

Hey, i've spotted a few issues with the new ui in OSX. (not sure if you prefer this to be in a new issue)

See the connection tab. it happens the diffeent panels that use it. Maximizing the window doesn't solve it.

[vlachoudis]

@Nandox7 Yes I would prefer it as an issue. But please can you explain a bit better what is the problem. Also the layout seems a bit strange on Mac (I don't have a Mac to test). But did you use the native python from the system or the one from fink?

[WillAdams]

Would it be possible to have an interface layout which works at 800x480?

That would allow usage on a Raspberry Pi w/ the LCD/touchscreen.

[vlachoudis]

In short the answer is yes!

There is a hidden and undocumented feature that some(not all) of the LabelFrames can collapse. E.g. if you click on the "State" it collapses and you can see everything on 800x480 or less bCNC -g 800x480 -r The bad thing is that I don't save the state on the ini for the next time. But can be done quite easily.

Longer answer: with the new UI you can fully customize it without touching the python code. Again undocumented feature. If you look the bCNC.ini in the [bCNC] section it contains the configuration what panels to show on every page and ribbon. You can add and modify these settings on your private version ~/.bCNC of the ini and configure it as you like. Furthermore you can change the fonts (some on the ini some from the x11 settings) and if possibly needed one can resize the icons with ImageMagick for a larger version possibly for a touch screen.

[HomineLudens]

Well done @vlachoudis every time a step ahead. Undocumented features... like that wonderful pocket path generator you was using in that screenshot?

[vlachoudis]

Indeed @Effer. The pocket path generator is a recent addition, but a bit primitive for the moment.

[samowitsch]

Good to know the undocumented features ;-) I am also using bCNC on an RPi with 800x480px TFT. Some features are not working properly with this resolution, e.g. Terminal input prompt not visible, status bar at the bottom of the window is also not visible.

[vlachoudis]

@samowitsch you are right, I didn't test the terminal. It had the default minheight and was not fitting in the 480px. I reduce it the minheight and now it works on 480px. The status line I don't understand why is not visible

[samowitsch]

@vlachoudis cool thx for the terminal fix! I can't reproduce the status bar behavior? I think the taskbar uses to much space (i changed the taskbar settings) and the bCNC window was to small. The status bar is visible now.

[samowitsch]

@vlachoudis is it possible to place the control buttons under the control tab above status and state? It can close/collapse the state ui to reach the control buttons on RPi. But for me, controls under the control tab has high priority and have to be placed on top ;o)

[vlachoudis]

@samowitsch yes it is possible by changing the .bCNC file See the bCNC.ini and copy the relevant lines to .bCNC and change the order of how the widgets are displayed

in the [bCNC] section this is the default control.page = DRO State Control You can change it to control.page = Control DRO State

[samowitsch]

Cool ! :thumbsup:

[winder]

Food for thought and slightly orthogonal to the discussion so far. I've been thinking about this problem for a long while (while developing a similar application). Having a good out of the box experience is obviously important, but advanced users are always going to want something slightly different or more tailored to a specific application.

Eventually I started considering solutions which allow for modular GUIs - for instance an IDE with movable panes. With windows as modules you can build various default profiles based on discussions like this instead of trying to optimize around the lowest common denominator.

There is an "AUI" toolkit for wxWidgets which supports this, and also similar functionality in Qt. Both of which appear to have Python bindings. I've built a proof of concept application to explore this idea, if you'd like to see it in action you can find a "platform" download link on a certain incumbent GUI's download page.

[vlachoudis]

Thanks @winder I will give a look on your implementation. The use of tkinter was a choice from the beginning to have something simple with no additional dependencies (it is the default toolkit of python). Actually I like a lot tkinter is very simple to program but limited in capabilities with respect some of the modern toolkits. However it has some very powerful widgets like the Text() and the Canvas() which I don't find in other toolkits. At the present state of the code it would require a lot of work to change it for another toolkit, especially what it concern the canvas. I would say it is easier to write my self the graphical customizations drag'n'drop of the various frames, than re-writing the program. But I would put it low in priority.

[auhopu]

From an end user perspective, the most clever UI I have ever seen is Lightroom. It is able to handle tons of functions while presenting to the user only the ones that are needed at any given time/stage and hide all the rest.

It is organized in modules. Within each module, there are collapsible panels. Inside each panel there are collapsible submenus.

Interestingly enough, there is a new GRBL controller called grblControl which indeed uses some of the concepts above. I personally find its interface very clean and intuitive. I will still use bCNC for what's under the hood. But if the looks get as good as the brain, it would be unbeatable :)

[vlachoudis]

As I said a couple of times, bCNC is written in tkinter, right or wrong, see the above comments. To re-write it in another toolkit it will be a huge effort which I am not willing to do now. I have practically re-written a good fraction of the widgets to include more modern functionality than what was provided from tkinter.

However some of the functionality you are mentioning is already there, undocumented and well hidden :) Most (not all) of the frames are collapsable. Click on the "State" labelframe and it will collapse. I have to do it for the rest (is not a big work) simply I have to remember to do it.

Also the interface, tabs, ribbons and the side-left panel are fully configurable from the user ini file. You can put what ever you want in what ever panel you like (with a few exceptions only). Unfortunately is not customizable graphically but you need to edit the ini file.

Lastly bCNC didn't start as a sender program, it started as a graphical editor for gcodes, and provides a lot of functionality in this respect, and I still use it as such. Removing all this functionality it will be easier to simplify the interface and make it more intuitive. Of course it doesn't mean that it cannot be intuitive including all this functionality.

Ideas and help are always welcome. Even simple things like providing new cleaner icons, suggestions on layout or functionality and of course documentation.

When I am used to something it is not easy to see the drawbacks and the pitfalls the new users are facing. It would be great to have input from new users.

[CarlosGS]

bCNC wins at optimization and user re-configurability, that's for sure! :-) Elias, you have to consider that most CNCs have a dedicated computer that is not very powerful. I don't think it is convenient to have a program that makes such an intense use of graphics; in my view, it is functionality what matters.

On Wed, Jan 27, 2016 at 2:47 PM, Vasilis Vlachoudis < notifications@github.com> wrote:

As I said a couple of times, bCNC is written in tkinter, right or wrong, see the above comments. To re-write it in another toolkit it will be a huge effort which I am not willing to do now. I have practically re-written a good fraction of the widgets to include more modern functionality than what was provided from tkinter.

However some of the functionality you are mentioning is already there, undocumented and well hidden :) Most (not all) of the frames are collapsable. Click on the "State" labelframe and it will collapse. I have to do it for the rest (is not a big work) simply I have to remember to do it.

Also the interface, tabs, ribbons and the side-left panel are fully configurable from the user ini file. You can put what ever you want in what ever panel you like (with a few exceptions only). Unfortunately is not customizable graphically but you need to edit the ini file.

Lastly bCNC didn't start as a sender program, it started as a graphical editor for gcodes, and provides a lot of functionality in this respect, and I still use it as such. Removing all this functionality it will be easier to simplify the interface and make it more intuitive. Of course it doesn't mean that it cannot be intuitive including all this functionality.

Ideas and help are always welcome. Even simple things like providing new cleaner icons, suggestions on layout or functionality and of course documentation.

When I am used to something it is not easy to see the drawbacks and the pitfalls the new users are facing. It would be great to have input from new users.

— Reply to this email directly or view it on GitHub https://github.com/vlachoudis/bCNC/issues/75#issuecomment-175634719.