Some remarks on the behavior of some of the widgets

[ReblochonMasque]

Following are notes of my first impressions when running the examples provided; this is not saying that the behavior of the widgets should be changed; it is more to open a discussion, because the object behavior differed from my intuitive expectation.

EntryGrid & LabelGrid:

Should probably be able to choose which row to delete. adding/deleting a row would be better if it did not move the buttons --> maybe place them on top & set the width?

Graph:

Should probably be resizable with the window, by default

Led:

Maybe a click on the LED should toggle the on/off? ...or maybe not? In the examples: led.to_grey does not accept an argument; this is inconsistent with the other colors. Maybe it should take an arg, but ignore it?

RotaryScale:

In the examples, the increments go over 100 while neither the display nor the gauge do. That is, after clicking over 100, reversing of the dial, and values, are lagging when pressing decrement. The same is true at the other end of the scale. It seemed a bit odd.

Cheers. Fred

[slightlynybbled]

I will leave this issue up for when I'm working on things. This repo grew up organically, meaning that I found that I was using similar widgets between projects, so there are things that aren't ideal that could use some polishing. Thanks for the feedback!

[slightlynybbled]

I have implemented most of your feedback into the EntryGrid, LabelGrid, and RotaryScale examples. I would like the examples to be minimal, so I don't wish to create fully functional and validated GUIs with them, just to use for demonstration and basic testing. I feel like the changes still qualify as minimal examples.

No changes to the graph widget or example.

As far as the LED comment, I really like the idea of a clickable LED as a button-like indicator. I will definitely use that functionality! I am going to create that as a separate issue.

Look forward to your thoughts,

[slightlynybbled]

Like I mentioned previously, I really liked the LED idea. I added the changes to the class since they were relatively modest, see issue #30 . Please let me know what you think.

[ReblochonMasque]

OK, I'll have a look.

One more question: Why did you choose to subclass tk.Frame for the SevenSegmentsLCD, and not tk.Canvas? I would probably have subclassed tk.Canvas, or used a Canvas inside a Frame; what are your reasons?

[slightlynybbled]

When I was looking at the problem of creating a seven-segment display, I was initially going to try a tk.Canvas element, but it hit me that the .columnconfigure(row, weight=x) would be a very natural, auto-scaling element that added no other images or potentially awkware canvas manipulations to the lib. In short, it just seemed simpler to me to turn "on" an LED by row/column at the lowest level.

I suppose that the short version is that I tried it as a frame and it simply worked. After it worked, I didn't try it a different way.

[ReblochonMasque]

Okay, thank you!

[slightlynybbled]

@ReblochonMasque Should I consider this issue addressed? Just going through trying to clean things up.

[ReblochonMasque]

Yes, please.