jepler: touchy's mdi is now ugly and weird. can you tell me what to do?
I don't like how after you press one of the G buttons, you have no feedback until after you do something like 1, Next
cradek: I notice that "G" is greyed out before I press "1"
I dunno if you could figure out how to put an insertion cursor in those fields
a GtkLabel has a property called curor-position which implies that it can show one..
I could surely put an underscore at the end of the highlighted one
but that'll encourage people to try to tap to move it around or something crazy like that
An underscore is worth trying I think
maybe never grey out the top one?
the top one is always sent - probably makes no sense to show it disabled
(wonder what mdi command it sends with just "G" showing)
oh, hm, I see what you mean
this doesn't fix the rect/polar complaint though
the "current" one shouldn't look "disabled" even if you haven't entered any letters yet
disabled has a special meaning - it means that word isn't sent if you push "go"
so I think it has to work this way (for at least all but the first line)
are you saying that some code depends on the widget being in a certain state?
hm, press G/Rtheta, 4, Next -> crash
or are you talking about what the user understands about what is on the screen?
yes the latter
if the letter is greyed, that word isn't sent, even if that's the current line
I am seeing it in a different way -- "greyed out" meaning "can't interact with"
yeah that is more standard
you think it's enough feedback that the word is empty (meaning it won't be sent?)
the user arrives at a word in one of two ways: he taps it to enter a number there; or he arrives there by "next"
I think it's easy to visually put together the dark/normal words and see the mdi command as it will be sent
in the first case it's perfectly natural for the letter to look enabled
in the other case, if the user taps something else, it'll change to be greyed
is this change part of a solution to the problem I started with where /xy and /rtheta are (even more) magical because the display doesn't show the results of which one you pressed until later?
(I'm agreeing with you more and more about the weirdness of those being disabled even though you can poke them and interact)
I think I see how to change it to only looked "disabled" when not the edited line, testing now..
I'm not sure about your XY vs @^ mode
maybe they should always look enabled, except that @^ disables if you enter in X or Y, and vice versa
[03:53:54] <jepler> http://emergent.unpy.net/files/sandbox/0001-don-t-show-current-mdi-line-as-disabled.patch
(I haven't pulled the @^ version yet, so maybe it doesn't apply)
it does apply
[03:55:54] <cradek> http://timeguy.com/cradek-files/emc/looks-incomplete.png
if in this state I push cycle start, I get the perfectly good MDI command G3 J3 F10
that makes you unhappy
I think the Z being dark like the 'active' words (the ones that will be sent) makes it look like it's in an unfinished state
then don't tap that line
and still while in this state, I can poke the ('disabled') X line
I don't think this solves anything - it doesn't change it so disabled means the normal thing (you can't interact with it)
yeah I'm starting to see that
the colors only half-accidentally look like the usual 'disabled' style
there's nothing usual about this ui really - maybe a different scheme would avoid looking like the user ought to know what to expect (and then surprising him)
maybe bold/nonbold for 'word will be sent'
right justify the inactive letters?
comment them out, like (X)
(you could look down the left column and see just the active ones)
hmm maybe that
right justify might be nice too
maybe strikethrough for the ones that haven't been set
did gnome printscreen put the mouse pointer in that screenshot?
right justify is kind of like the 'two columns' thing where you have arrows to select/deselect from a set by moving between columns
I'm so used to xwd and anything based on it not giving an indication of the pointer
yes I used the gnome-whatever
wonder how to right justify
I did that earlier actually
I bet the bold/nonbold is not overt enough
not sure about strikethrough - seems like it might look like errors
1.0 indicating right/bottom, 0.0 indicating left/top, and all values in between being valid
yeah I don't like strikethrough for this
[04:12:16] <cradek> http://timeguy.com/cradek-files/emc/justify.png
you sure can scan down the left side and see what the command is
it doesn't use something that looks like 'disabled' in a nonstandard way
those are the benefits
I think the drawback is it looks otherworldly
do you have to hit the character, or does the line suffice?
you mean if you want to select it by poking? anywhere on the line
more often I just poke next
can you change the background color of the inactive lines instead?
there will be 3 colors then, and for some lines two colors may be appropriate (inactive AND currently selected for editing)
I confess that I can't try this at the moment - mind if I ask some possibly silly questions?
by all means
so, what if you're at the X line - what do all the things below X look like?
I don't understand
if I poke X now, the X line turns white
well, say I've just hit the G/XY button, then the 3 button. presumably, the list of things I could use with G3 appear li the list
only when you poke next
and what do they look like?
black or gray
G/XY, 3, Next -> it fills out wih X,Y,Z,I,J,K,R,F
currently, gray on the left. this proposed change, black on the right
ok, so "unvisited" look the same as "visited but skipped or no value given"
it doesn't mean visited -- gray means "unless you add a number here this word won't be sent"
that is the initial state of all words
[in the current design]
that may be the thing that should change, not what an unused word looks like
jeff's very valid objection is gray normally means "you can't interact with this widget for some reason"
ie, what context matters to the user
sorry - what may be the thing that should change?
the thing that causes a visual differentiation between words
yes I think that's what we were working on?
the right/left for instance
well, that's my question. are you working on changing what the existing categories look like, or what the categories are (or both)?
sorry - what is a category?
the status of the various lines in that G-code word list
legal/illegal (negative feed word, for example, if that's possible to ender)
I'd like the user to be able to see which one is currently picked for editing - I'd also like the user to know which words will be sent if he pokes cycle start
maybe a preview line somewhere on the MDI tab
touchy does not try to tell you what makes correct gcode. you can type a syntactically nonsense gcode if you want
like F-99 for instance
the only smarts it has is it gives you the list of words (letters) appropriate for the G/M code
well it won't let you add two - or . either
but that's about it iirc
"better" error checking may be something to think about later
you get a very good error message as soon as you poke cycle start
validation on every entry poke is madness
well maybe you could do 'this makes sense right now and would not error if you sent it'
complete validation probably is, but partial is possible
whether it's useful enough to implement is a different question
but the state of that would change constantly (and distractingly) as you enter stuff
in any case, that's a distraction
(we have that in the touch off screen in AXIS)
oh, I guess I was thinking of making the word look different if there's an error when you hit next or another word
you are presented with a blank entry field. you type -, and it displays what looks like an error
yep. validation while the user is typing is a disaster
in this part of touchy the user is always 'typing'
but yeah, it's a tangent
so, a separate text widget that shows the G-code line that would be sent may be a good way of indicating which words are currently "in use"
as I see it, the problems with that are it takes up space, and you have two things that show nearly the same information, only one of which you can manipulate
but you can clearly indicate that the text widget can't be manipulated by graying it out
seems like it's unusual to show two 'views' into the same data on one screen
I don't think so
yes you could definitely make it look like you can't change it
not in the case where a single view has to show a lot of things, in addition to being an edit widget
a lot being used in the G-code or not, in addition to "being edited" or not
slightly better? http://timeguy.com/cradek-files/emc/justify.png
uh. what changed?
I didn't notice it when I loaded the image
just a little whitespace so the letters aren't touching the edges
yes, actually that is better
for jepler: http://timeguy.com/cradek-files/emc/0001-Show-status-of-mdi-words-in-a-less-confusing-way.patch
this is the two-column change fwiw
EMC: 03cradek 07master * r600b3d26db73 10/src/emc/usr_intf/touchy/mdi.py: Fix traceback when mdi words don't include x,y
thanks for all the input
> The result is that I successfully run insmod. But when I rmmod it, I got "fragmentation fault" error and at this time i can't visit the files under /sys any more. I am confused.
huh, I've never seen that error
emc/rs274ngc/interp_internal.cc:150: warning: array subscript has type 'char'
why does gcc warn about this? what am I missing?
jepler: ugh, on dapper, http://timeguy.com/cradek-files/emc/0001-Show-status-of-mdi-words-in-a-less-confusing-way.patch
doesn't work right at all
it puts the right-justified ones half a character past the right edge
is there an anchor point that gets magically set in later GTK versions?
the fraction of horizontal free space to the left of the child widget. Ranges from 0.0 to 1.0
right, but does that align the left edge, center, or right edge?
in later versions, it may do the smart thing
there is also 'justify' which seems to have no effect
yeah it sounds like a very dumb setting, and this old gtk version seems to do what it says
if 1.0 of the horizontal free space is to the left of the child widget, it seems like it's right that I see only free space
yep, if the text anchor/alignment point remains on the left side
(of the text)
it's confusing that justify doesn't do anything
[17:12:15] <cradek> http://library.gnome.org/devel/gtk-faq/stable/x798.html
sometimes "justify" means "modify the width of spaces between words so the right side of the column is straight"... if there are no spaces, maybe it does nothing
it calls me an idiot then tells me to do the thing that doesn't work
jmkasunich: yeah maybe that's what they mean in the docs (but they're too busy being snide to say it)
all signs point to align=1.0 being the thing to use
ok this gtk is just busted if you specify a requested width in chars for a label > 0
works and looks ok if I use width_chars -1 and width_request (?) of 60 (units?)
new patch at the same url: http://timeguy.com/cradek-files/emc/0001-Show-status-of-mdi-words-in-a-less-confusing-way.patch
if someone could try it on hardy or newer that would be wonderful
(I'm still not sure I like this appearance)
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-12-29.txt
EMC: 03seb 07master * r80096627a559 10/ (3 files in 2 dirs): add a firmware package for the 3x20
EMC: 03seb 07master * rc8a4b98b4982 10/docs/man/man9/hostmot2.9: shorter simpler path, to squelch a groff warning
EMC: 03seb 07master * r6d9c3dd131a3 10/docs/man/man9/kins.9: fix the syntax of the name of this manpage, for mandb