Ideas for a successor of DWC
-
@chrishamm who remembers all the hate M$ received when releasing Windows 8 in 2012... however much sense it makes to build a desktop OS around this kind of UI is debatable at best, imo it's still a very good design approach and I'm very excited to play around with this once it takes shape.
what's it gonna be called, btw? DWC2? DDWC (dynamic duet web Control)?
-
@sonderzug Since it will be a NodeJS app it will be possible to turn it into desktop app will without much trouble, I think. I'll call it DWC2, which is why there is no DWC 2.0 release yet.
-
@chrishamm said in Ideas for a successor of DWC:
By that I mean the responsive grid that will allow you to customise the pages as you like
Idea: Be able to SAVE, and maybe in a way that is shareable, the customization.
-
@brunofporto Yep, that is going to be possible - OEMs will need this feature, too. I doubt it will be feasible to implement dynamic menus right in the first DWC2 version but I'll keep an eye on it while porting everything over to the new framework.
I've got the first draft of the file structure ready but I decided to stop using Element-UI because it violates so many design rules that would enable theme support (e.g. colour keys in layout/HTML files instead of CSS). Instead I will focus on Vuetify, iziToast and vue-chartjs. Vuetify also provides light+dark themes out of the box and I'm sure many users will want to see that when upgrading to a newer DWC version.
-
One thing:
When I send a command from the top "send" area there is no indication that it was sent or executed!!! If at least the text box was cleared was a nice indication. But it does not even do that
So sometimes I execute more than once the same command.So another suggestion is to always have clues that something was executed! Like a color quick change at a Macro's button holding it like that until it finishes execution, for example, the text box been cleaned after pressing enter and the queued indicator mentioned earlier.
-
Hmmm. I see in the history box below the GCode box that it shows that it's sent it, even if I can't see that it's executed.
Personally, I'd like a better history on the GCode box. Sometimes, I want to send the same sequence of commands. Kind of like with a linux bash shell. That way, I can send a sequence of commands easily without typing it out again, or stuff like redefining my Z probe between manual and having the piezo probe quickly.
(Yes, I could just define these in macros, but for whatever reason, I don't.)
-
I second this.
-
Me too. Perhaps we could have a drop down list giving the last 8 or so commands sent, after removing duplicates?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
It would be nice to have a search future in the history.
Like a fish shell on linux. I think the history could be nicely saved in localStorage, it can store much data. -
@dc42 said in Ideas for a successor of DWC:
Me too. Perhaps we could have a drop down list giving the last 8 or so commands sent, after removing duplicates?
When using DWC on a desktop computer, with a keyboard, using the up arrow key to select previous commands, like in linux shell, is much better. But it does not work with a tablet, with only touch screen... So, both systems should be implemented (with more than 8 commands in the history for keyboard usage).
And for keyboard usage, history search should take care of the first chars entered (if I start writing G1, using the up arrow key should only show me commands in the history starting with G1).
-
@fma said in Ideas for a successor of DWC:
@dc42 said in Ideas for a successor of DWC:
Me too. Perhaps we could have a drop down list giving the last 8 or so commands sent, after removing duplicates?
When using DWC on a desktop computer, with a keyboard, using the up arrow key to select previous commands, like in linux shell, is much better. But it does not work with a tablet, with only touch screen... So, both systems should be implemented (with more than 8 commands in the history for keyboard usage).
Surely a drop down list would work for tablets too? Touch a down-arrow button to popup the list, then touch the entry in the list that you want. But DON'T then require Enter to be pressed, have a Send button instead.
-
Yes, I think the drop-down is mandatory for tablets, but for desktop computers, linux shell history, only using keyboard, is much better.
I only use the console when I need to tune things, and I often repeat commands without changing them, or changing a char or two. So hitting arrow up key, then enter, is very nice (this mean focus should stay on the line edit widget). Using the mouse is not that fast.
-
@brunofporto The new web interface will block as long as pending G-codes have not been confirmed by the firmware so I could put the Send button into a loading state and disallow sending of more codes until the last code has been confirmed. This will be a relatively big change compared to DWC1 but it will make use-cases like this way easier.
@SupraGuy @dc42 @fma This is already on my list - in fact I think it would be even better to clean up the codes before they are stored in the local cache, i.e. to remove comments as well as duplicate spaces. Also I've been thinking about integrating a short dictionary for every supported code so that you could actually search by keywords for a code. That way you would not have to look up codes every time on the Wiki when you want to do something special.
I'm happy to report I've been making progress and if everything goes well, I hope I can present a first beta by the end of this week. We'll see
Duet software engineer
-
That's great news.
FWIW, though I like the "up arrow" history, and is what I'm used to with Linux shells, a drop down box is perfectly acceptable. It's a web interface, I don't expect that you're going to check what browser/client I'm using and provide different interfaces. (Arrow keys usually work on drop-down boxes anyway.)
I use a desktop PC with full mouse/keyboard, a desktop PC connected to my TV with a trackball, no keyboard, my phone, or one of a couple of tablets, and just to make things interesting, sometimes the tablet will have a bluetooth keyboard and mouse. Probably the only consistent thing is that I'm most likely using Chrome/Chromium, but I won't guarantee that.
I like the dictionary idea, though it being a web browser interface, that feature could be offloaded to an Internet service, to reduce demand on the control board processor. Since browsers all support tabs now, it's easy enough to keep a wiki page open, and bookmark it. (I regularly cache the one from here, and the one on RRF anyway, so it's on my local NAS, that way I can use it even if Internet is down.)
-
@supraguy said in Ideas for a successor of DWC:
FWIW, though I like the "up arrow" history, and is what I'm used to with Linux shells, a drop down box is perfectly acceptable. It's a web interface, I don't expect that you're going to check what browser/client I'm using and provide different interfaces. (Arrow keys usually work on drop-down boxes anyway.)
That's OK (and more or less what PanelDue does); but when using a browser I am so used to the focus not being where I want it to be that I always use the mouse. What I don't want to do is use the mouse to select the command I want, and then have to switch to the keyboard to press Enter.
-
Thanks for the clarification.
Yes, what I'd want is the way that standard browser drop-down boxes work, where a click is enough to select the item from the drop-down box, and then assume that there will be either a "submit" button to click on, and that the enter key will act the same way that a web form typically does where it's default action is whatever the page "submit" action is, unless focus is in the drop down list, where it will behave the same as a click on the item. This is pretty standard web form interface, and I would expect overall behavior to be the same.
-
@chrishamm said in Ideas for a successor of DWC:
Also I've been thinking about integrating a short dictionary for every supported code so that you could actually search by keywords for a code. That way you would not have to look up codes every time on the Wiki when you want to do something special.
I've always kind of like the way "Chilipeppr" does this. Each "word" (G or M) in the G-Code log just below the entry area has a "hover over" link to the Wikipedia entry regarding that word.
Example:
-
Also, if you hover over the line, without hovering over a G/M word, you get this:
Which shows the move, and offers to send a move, set the "start" position (i.e. zero the current work coordinate system to this point).
-
@chrishamm I would try to include tooltips on gcodes (could be done on browser side) and gcode preview (could be done with three.js and some script that would convert the gcode to some supported format), I think a lot of work could be offloaded to browser or a separate running RPi (that would be a realllyyyy cool idea the more I think about it)
