winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.9k stars 766 forks source link

Window location and size issues. #914

Open groberts22 opened 6 years ago

groberts22 commented 6 years ago

I apologize if this seems trivial or if I am failing to understand something obvious, but a couple of the display windows that I rely on appear to have limited resizing flexibility and thus cannot be easily combined with other windows that I frequently use.

  1. Whenever I open the send progress window it expands to fill most of the right side of the screen. This frequently changes the width of the other windows I am viewing and forces me to reset them.
  2. Whenever I open a g-code file for editing it appears in the same window as the visualizer. I typically set the width of the visualizer window to be fairly narrow, and would prefer to have the editor appear in another area of the screen. Is this something that can be changed? Again, I apologize if these issues seem trivial, but would appreciate any help you can provide. Thanks.
breiler commented 6 years ago
  1. Could you take a screen shot?
  2. I've noticed the same thing and I would also like the editor window to save it's location. This becomes particularly annoying if you use the workflow helper and switch between files. I can have a look at it.
breiler commented 6 years ago

Regarding the placement of the g-code file editor as the same window as the visualizer. I couldn't reproduce your problem... =(

However the problem I had with the Workflow Helper is because it uses the same "layout mode" as the editor. This causes the editor to steal focus as soon as a new file is selected in the Workflow Helper. I tried moving the Workflow Helper to left which resolved this issue.

screenshot 2018-02-22 13 35 12

Does anyone have an opinion on this?

groberts22 commented 6 years ago

@breiler thanks for the response. Here is a screenshot of the way I currently have my desktop organized. The first problem occurs if I attempt to place the Send Progress window in a box on the left hand side of the screen - say, below the state window or sharing the same window with it. Either action immediately expands the windows in that column and shrinks the column on the right hand side. I think the minimum width of the box must be set to 80 or 130, which doesn't seem necessary given the width of the information contained in the window. The second problem seems to have disappeared. What was happening was that whenever I opened a g-code file for editing it was opening in the same window regardless of where I last had it opened. I just tried (and failed) to reproduce the problem. Strange. Maybe some type of Rumpelstiltskin effect. :)

image

breiler commented 6 years ago

Most of the panels doesn't scale well, only DRO and Macros can become really tight. This would require a new layouts for most of the panels.

When I fiddled around with the layout I noticed that these types of windows are in "editor mode" which are used for opening files. I guess if you are unlucky you would get your Rumpelstiltskin behaviour where the gcode-editor will be opened in the visualizer area. window

groberts22 commented 6 years ago

Thanks. In any event, these are small problems. The display is really remarkably flexible. If everything worked exactly the way we want it to, we would probably just end up changing our minds.

On Thu, Feb 22, 2018 at 1:22 PM -0500, "Joacim Breiler" notifications@github.com<mailto:notifications@github.com> wrote:

Most of the panels doesn't scale well, only DRO and Macros can become really tight. This would require a new layouts for most of the panels.

When I fiddled around with the layout I noticed that these types of windows are in "editor mode" which are used for opening files. I guess if you are unlucky you would get your Rumpelstiltskin behaviour where the gcode-editor will be opened in the visualizer area. [window]https://user-images.githubusercontent.com/8962024/36554906-d87eeeda-1800-11e8-880a-ded9994ba346.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/winder/Universal-G-Code-Sender/issues/914#issuecomment-367773312, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYmt51eqgKwqS11dYdAyiu2E0s09ejrvks5tXbBSgaJpZM4SOFRI.

This electronic message and its attachments contain information from the consulting firm of Charles River Associates that may be confidential or privileged. If you are not the intended recipient we ask that you notify us immediately via reply e-mail and delete or destroy this message and any copies of it. Thank you for your cooperation.

winder commented 6 years ago

The gcode editor isn't very good right now.

The default location is definitely inconsistent, no matter what settings I tried I couldn't get it to show up where I wanted it (center of the screen with visualizer to the right). Even if you manually setup the windows, the editor still moves around sometimes when you open a new file or restart UGS.

The "NetBeans" way to deal this would be to have the editor show both the gcode source and visualizer (in @breiler's screenshot see the source box, there would be another box saying something like visualizer). That isn't really the UX I was going for though, I like having the visualizer and gcode open side by side.

A better way to go about this might be to utilize the "roles" feature in netbeans, so that there are multiple layouts depending on if you are editing or sending, that way when you go into editing mode most of your windows would go away (i.e. DRO, console, macros, etc). Then there would be a default/sending mode which brings out another set of windows. That's a pretty big project.

groberts22 commented 6 years ago

I can imagine a number of different scenarios (I often find myself wanting to have the console and the g-code open side-by-side when i am reviewing/testing code). That is the beauty of being able to place the modules in separately movable and sizeable windows. I keep telling myself that I need to learn more about the framework employed by UGS so that I would have a better sense of what is possible, but that project has not made it to the top of the stack yet. In any event, I appreciate how far you have taken this project. Thanks.