Laser Panel - More coherent laser control #623
Conversation
|
I quite like the concept. It brings things together and has a nice look to it. Optimisation SettingsI think the optimisation settings are something that a user may want to change frequently, and so might be better on this panel and not on a subpanel. Terminology
Other functionality
Longer term UI strategyWhilst I am for an evolutionary approach (perhaps with this Laser panel as a first next step), I think it might be helpful if we had an overall UI strategy in mind. I am not an expert on Whisperer or RDWorks or Lightburn, but I have a feeling they have (what we might call) "Panel Sets" which relate to the functionality you are using at the time. So when you are doing drawing, positioning etc. i.e. graphical you get a set of panels which relate to e.g. doing things in the scene. When you move onto setting up a burn, then you don't want the scene-related panels, but instead want burn related panels like this Laser panel and Navigate. Inkscape also has something of this nature - the left panel (in the way I use Inkscape anyway) allows you to select major functionality groups - and the top panel changes when you select e.g. the Pointer/Selection Tool, the Nodes tool, Rectangle, Arc etc. Indeed, a previous 0.7 beta had a Tabs on the main ribbon - but these didn't change the entire panel layouts, just the main ribbon. So I am wondering whether we draw together these threads and have a Workflow tab bar at the top which activates a panel set. And the user can then define whatever panels in whatever configuration they like - in several bars along one side (LRTB) or on several sides. What do others think of this suggestion? |
I could probably include them as a different page. But, I also think maybe there should be a page for each laser you have installed. Subpanels have infinite real estate, tho a different page might too. Since the main thing is to allow this to control the lasers and the best way to do that is likely to tuck a lot of options in just that pane. So maybe it should also duplicate the functionality within Execute Job. Since there's a standard problem that at some point the operations become cutcode. And the user might need some guidance for that. But, also, if I made a different page (the pane is a NoteBook (https://docs.wxpython.org/wx.aui.AuiNotebook.html#wx-aui-auinotebook) the notebook has pages) for each laser they wouldn't all need different optimization settings. But, there might be a very common and reasonable workflow of compiling/optimizing a job and sending it to multiple lasers, or saving that job to disk and reloading it.
Yes, and some global settings are actually clearly device settings but have nothing to do with the controller board. Like the bed size parameters.
The intent there is that Device Settings would be like Devices and let you configure your lasers there. I guess it could be rebranded a bit.
Hm. In theory maybe. Since if we are using this for multiple laser control, we could want to control our lasers independently. And so if we got rid of the devices and rather gave each device its own page. There might be some useful things there. Though it might be better to just have the user select the device there and have it change those various settings.
Save certainly does, basically it's rather than send the job to the laser with start, we save the job to disk. Then we can load the job accordingly.
This is certainly the case. Since there's a number of longer term goals that might be well achieved by doing a good job at this.
They don't they have notebooks of different settings. They don't switch things based on what you're doing.
The functionality we'd be doing here would be like the Laser Work/Process Control Bar.
RDWorks: Lightburn: Whisperer: Autolaser: LaserGRBL LaserWeb Ultimaker Cura
That's accurate but some of that stuff would require some internal changes I've considered. Specifically I would tend to need a generic properties window based on a lookup. This is a bit weird but basically if you select things and you want things to changed based on the suggestion you often need something listening to the selections. This can be implemented in a couple interesting ways, but basically it would be a different part of kernel that basically puts different classes in the lookup and lets you listen to it for changes. If you are looking for a rectangle and something the user does selects a rectangle it triggers that code for you. You can then have panes like properties that listen to the lookup for anything that permits a get_properties or something like that and then can create a dynamic list of properties to be read and written accordingly. Then all anything needs to do is list their properties. Then the properties panel would know that the object in the lookup wants to let you modify something called
Switching some functionality in one by another selection might be generally doable, but it's likely more gui based and would need the panes to define some interactions there. Unless something like properties above was done.
This seems useful and I've considered some aspects of that before. But, not extremely relevant to the laser panel in general. Implementation wise I'm leaning towards Tiger's idea of switching the entire layout with the device. So we can define AUI perspective as device relevant setting. Which has a lot to recommend it. While having your layout radically shift when you change devices sounds weird, it wouldn't be too hard to share between devices and disable the disallowed panes and switch to the permitted panes rather directly. I still don't have a solution for the question of data source. I have a combo box in case you're getting the data to send from a file you loaded, from the scene/operations or from the planner that already optimized this stuff for you. Some of the programs around just send this file to the laser and load it, but don't require you to hit start. So it's just a load/send button. I don't love this, but it might end up being easier. Though it doesn't fix the issue with the sending from the established planner vs. sending from the scene and rebuilding the plan. This also shares some overlap with my wouldbe implementation of sewsorcy where embroidery fills would be delayed and then recompiled at points. Though in that case the only operation you have is save the embroidery file. Narrowing down the goals though makes this a bit easier and the gui a bit less crowded. While I threw this in a notebook because I thought it could have some good aspects, it's not really needed if I we went with Tiger's idea. It might be nice to have a notebook of large settings or maybe a properties pane. Or a large group of settings that maybe your laser would need depending on the type of laser. But, neither of those candidates actually requires a laser panel to be that complex. Only the question of data source seems to be remaining thorn in the implementation. Since compile this work and send it to the different lasers seems to be a pretty reasonable workflow. |
|
Most users (like me) probably only have one laser, but separate pages for each laser makes sense to me. My philosophy on copying UI ideas is mixed:
Reviewing how I use MK, I tend to work in phases.
For screen real-estate reasons it would be great if I could switch pane-sets to match my activity at the time. P.S. I use a touch screen windows PC for production, so resizeable buttons are great!! |
This is a more standardize panel design incorporating aspects seen in RDWorks, Lightburn and Whisperer. Have a single pane that lets you just execute your jobs.
There is a weird snafu with how the code currently works and the implications here. Namely with regard to simulate we create the cutcode to simulate the job. We also have code to load and save the file rather than sending it to the laser we send it to a file. This gives us some general load an egv and send it to the laser functionality. So there's a source selection thing that might select that. Is this data coming from the loaded file, the operations, or the stuff already done in the planner.