>
> My weekend turns out not to be my own so this is just a quick reaction
> to a preliminary exercise of LinuxCNC 2.6.0~pre with configuration:
> sim/gscreen/gscreen_axis. I realize Gscreen is a work in process and
> that the existing screens are as much experimental as they are finished
> product, but I'm looking at them as a user.
>
Thanks Kent this is exactly the info I am looking for.
> I did this exercise with a mouse and no touch screen.
>
> 1. While initializing, gscreen throws three warning messages (see below).
>
Yes I see one I can fix easily, the others are much harder - actually TOUCHY
throws the same errors as I stole the code from it...
> 2. Maybe it's just me, but I think it might be helpful if the visual
> style of the various buttons distinguished between two different kinds
> of button actions: momentary-closure and alternating-state (e.g., off/on).
>
Kent Themes play a huge role in this. The default Ubuntu theme sucks
in this regard. Please try other themes - I suggest Redmond as an
always-available
start.
On this same idea I am trying to think of visual clues for other stuff such as
what mode
gscreen is in - I hesitate to use too much color changes as that often clashes
in different
themes.
> 3. I finally located the "Quit" button which is hiding on the
> Preferences menu page (which I would title "Preferences" not "Preference
> stuff"). I'm not so sure that's the rigth place for it.
>
It's a compromise between being able to find it and not accidentally pushing it.
I agree it's hard to find the first time - not so much the second time. It's
also on
a screen that is always available. I'm up for other ideas.
I will fix the tab name (I will audit all the text when I update Gscreen for
locale)
> 4. Maybe it's just because I'm used to Axis in its default
> configuration, but the Estop/Machine button seems a bit strange. First,
> it's not so obvious that it is a button because of the placement of text
> and "leds" in it. Second, there are just three states: [Estop/Machine]
> off/off -> on/off -> on/on -> off/off. Do users generally equate
> machine-off with estop?
I think this is a case of what we are used to with all the other GUIs.
The fact of this is I could not think of a time when you would need a machine
to have all four states. This is a hold over from the translation from
electrical
to software.
In fact wanted only two states estopped and machine on but for technical
reasons that didn't work.
The other thought was that one should actually have an electrical estop system
so then this button becomes a status indicator.
I think I will keep it as is unless everyone completely hates it.
And in fact this is something that someone could change in a custom glade file.
In fact I think I will do that in the custom_gscreen config example.
>
> 5. The bottom action-buttons for graphics options like Zoom, Pan...,
> Rotate... are a bit confusing. I can perform all these actions within
> the graphics windows solely with my 3-button mouse without recourse to
> the bottom action-buttons. On the other hand, if I select, for example,
> the Pan Horizontal button, then the graphics windows behaves as if I'm
> holding down the appropriate mouse button as long as my cursor is within
> the window. This is disconcerting because anything I do in the window is
> undone in various ways as I move the cursor out of the window. Perhaps
> these action buttons are needed for touch screens?
Yes these buttons are needed for touchscreens and its even a bit clunky
at that. Untill Ubuntu understand touchscreen gestures it will clunky.
Couple of things I could do here. When in mouse mode I could disable the
graphics buttons or when in mouse mode and a graphics movement button
is selected I could disable the mouse movements then you use the + - buttons.
(not sure if you found that out)
Longer term I would like to play a bit with the graphics control as it annoys
me when I get the view just as I like then change view and It defaults to
zoom and pan that I have to adjust all over.
>
> 6. I have a few Kent-nits, for example, inconsistent capitalization and
> buttons overlapping adjoining text, but they can wait.
>
Yes and probably spelling too :) I need to also see if the terminology I
chose makes sense to users/machinist.
in another email you mention not liking icons without text.
eg the start/stop/pause buttons.
I have to agree somewhat. I don't mind icons when they are unmistakable
for function and fit the feel of the program. those particular buttons
don't fit the feel of the program. But for instance I don't mind the coolant
icons.
hmm I think they have text though....I will add text to all the icons.
I am not very artsy . If anyone has or would
like to make some more appropriate icons I would love to look at them.
> Overall, this looks nice and I like the direction you went with Python
> and Glade.
>
Python and glade lower the barrier for others to hack Gscreen to what they want.
Whether they do this within the customization option that exist or just edit
the
main Python files - I want to someone with medium skills to be able to do it.
Gscreen is just another stepping stone - Gscreen would not be, without gladeVCP,
GladeVCP's gremlin would not be, without AXIS and so on. Open source is such a
great thing!
Thanks again Kent for your critique.
Chris M
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
