UI on Mac OS X

[kliment]

UI on Mac OS X

[kliment]

a) The blank space at the bottom is for custom buttons! Try
right-clicking somewhere.

b) Lovely idea. Are you up for it?

c) The display is correct. The object would print off the platform. If
we auto-center, you don't notice the problem until the print starts,
which is bad. I would like a tool that transforms the gcode itself, but
we should NOT change the display.

On 11/12/2011 09:33 PM, Duane Johnson wrote:

So now that we've replaced the X/Y/Z buttons with a better UI, I'm looking at some other things that could use improvement. Since I'm on a Mac, I'd like to highlight some of the things that look odd or could be improved. I'm not sure if these things apply to all platforms:

http://dl.dropbox.com/u/118766/Ultimaker/pronterface-on-mac2.png

What do you think of:

a) reducing the height of the console on the right so that it matches the height of the gviz panel in the middle? We could then use the blank space at the bottom for other things, like a live graph of temperatures.

b) creating our own button control that does background colors on all platforms?

c) centering the gcode in gviz?

---

Reply to this email directly or view it on GitHub:
#91

[kliment]

Just remembered, mac os is the only platform where there are no
backgrounds on the buttons, and I hear this is fixed in the latest wx
for mac. I definitely don't like the idea of nonnative-looking controls
on other platforms. Can you please test with the latest wx?

On 11/12/2011 09:33 PM, Duane Johnson wrote:

So now that we've replaced the X/Y/Z buttons with a better UI, I'm looking at some other things that could use improvement. Since I'm on a Mac, I'd like to highlight some of the things that look odd or could be improved. I'm not sure if these things apply to all platforms:

http://dl.dropbox.com/u/118766/Ultimaker/pronterface-on-mac2.png

What do you think of:

a) reducing the height of the console on the right so that it matches the height of the gviz panel in the middle? We could then use the blank space at the bottom for other things, like a live graph of temperatures.

b) creating our own button control that does background colors on all platforms?

c) centering the gcode in gviz?

---

Reply to this email directly or view it on GitHub:
#91

[canadaduane]

a) The blank space at the bottom is for custom buttons! Try
right-clicking somewhere.

Hmm, this is really not intuitive. I wonder if we could add a bordered pane that labels the area? something like:
+-- Custom Commands --+
| |
+-----------------------+

Possibly even add text in the center that says "(right click to add)" or something like that.

b) Lovely idea. Are you up for it?

Based on your other comment, I agree native controls are better if supported. I believe I'm running the latest wx:

[16:07|~/Others/Printrun (master*$%)]$ arch -i386 python
Python 2.7.2 (default, Oct 29 2011, 22:03:47) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> wx.VERSION
(2, 8, 12, 0, '')

Oh, wait... it looks like something was released in September.. 2.9.2.4... is that the version that supports colored buttons on Mac OS X?

c) The display is correct. The object would print off the platform. If
we auto-center, you don't notice the problem until the print starts,
which is bad. I would like a tool that transforms the gcode itself, but
we should NOT change the display.

This doesn't seem to be the case for me. When I print it in the corner like that, it actually centers the extruder and then prints. This may be a consequence of following others' instructions that I don't understand, however :)

In any case, it seems like this is something that should at least be customizable. All of my gcode files are produced at coords 0,0 so I'd rather not fight the trend if possible.

[kliment]

On 11/12/2011 11:11 PM, Duane Johnson wrote:

a) The blank space at the bottom is for custom buttons! Try
right-clicking somewhere.

Hmm, this is really not intuitive. I wonder if we could add a bordered pane that labels the area? something like:
+-- Custom Commands --+
| |
+-----------------------+

Possibly even add text in the center that says "(right click to add)" or something like that.

I recommend we leave that for later. The problem is the custom buttons
are spread out. The first ones use the empty space at the top and other
ones then spill to the bottom pane. I'll talk to keegi, who made the
custom buttons work at all, about how to best make them more visible.

b) Lovely idea. Are you up for it?

Based on your other comment, I agree native controls are better if supported. I believe I'm running the latest wx:

[16:07|~/Others/Printrun (master*$%)]$ arch -i386 python
Python 2.7.2 (default, Oct 29 2011, 22:03:47)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> wx.VERSION
(2, 8, 12, 0, '')

Oh, wait... it looks like something was released in September.. 2.9.2.4... is that the version that supports colored buttons on Mac OS X?

I think so, but I have no access to a mac.

c) The display is correct. The object would print off the platform. If
we auto-center, you don't notice the problem until the print starts,
which is bad. I would like a tool that transforms the gcode itself, but
we should NOT change the display.

This doesn't seem to be the case for me. When I print it in the corner like that, it actually centers the extruder and then prints. This may be a consequence of following others' instructions that I don't understand, however :)

In any case, it seems like this is something that should at least be customizable. All of my gcode files are produced at coords 0,0 so I'd rather not fight the trend if possible.

Gcode files SHOULD be centered in the middle of the build platform. You
have some weird workaround if that's not the case for you.

---

Reply to this email directly or view it on GitHub:
#91 (comment)

[canadaduane]

On Nov 12, 2011, at 4:51 PM, kliment wrote:

On 11/12/2011 11:11 PM, Duane Johnson wrote:

a) The blank space at the bottom is for custom buttons! Try
right-clicking somewhere.
...

I recommend we leave that for later. The problem is the custom buttons
are spread out. The first ones use the empty space at the top and other
ones then spill to the bottom pane. I'll talk to keegi, who made the
custom buttons work at all, about how to best make them more visible.

Sounds good.

c) The display is correct. The object would print off the platform. If
we auto-center, you don't notice the problem until the print starts,
which is bad. I would like a tool that transforms the gcode itself, but
we should NOT change the display.

This doesn't seem to be the case for me. When I print it in the corner like that, it actually centers the extruder and then prints. This may be a consequence of following others' instructions that I don't understand, however :)

In any case, it seems like this is something that should at least be customizable. All of my gcode files are produced at coords 0,0 so I'd rather not fight the trend if possible.

Gcode files SHOULD be centered in the middle of the build platform. You
have some weird workaround if that's not the case for you.

Skeinforge doesn't know the size of the Ultimaker's build platform... at least, I don't know of a way to set it. In any case, the output of skeinforge on an STL file is a gcode file that is centered at 0,0. I'm new to this, so I don't know exactly what's going on, but these are the default settings.

[kliment]

Skeinforge doesn't know the size of the Ultimaker's build platform... at least, I don't know of a way to set it. In any case, the output of skeinforge on an STL file is a gcode file that is centered at 0,0. I'm new to this, so I don't know exactly what's going on, but these are the default settings.

Then you likely have a start.gcode file that moves the nozzle to the
middle and sets that as the zero point. The usual way (with skeinforge)
is to set the center point in the multiply module, and set rows and
columns to 1 to prevent it from actually multiplying. I don't know what
sort of hack the ultimaker is using there. I thought only Makerbot did
crap like this, because they had no homing capability on the cupcake.

---

Reply to this email directly or view it on GitHub:
#91 (comment)

[canadaduane]

Then you likely have a start.gcode file that moves the nozzle to the
middle and sets that as the zero point. The usual way (with skeinforge)
is to set the center point in the multiply module, and set rows and
columns to 1 to prevent it from actually multiplying. I don't know what
sort of hack the ultimaker is using there. I thought only Makerbot did
crap like this, because they had no homing capability on the cupcake.

Yes, this makes sense now. I copied a start.gcode file from the ultimaker discussion group. Here is a discussion thread about the topic of centering the coordinate system:

http://groups.google.com/group/ultimaker/browse_thread/thread/d0a502195954f261/8efea9c39f75b787