Re: lists & widgets
David wrote:
> 1. Traditionally, a radio button represents an exclusive choice -
> you can only select one option from the group. Your rbuttons seem to
> act like checkboxes.
David, you obviously did not notice, I have both. Under misleadingly
similar names. rbutton is really a checkbox in disguise, and rbuttons
is a cluster widget with the behavior you want. Run the other example
and you will see.
> 2. It would be nice if the label were part of the clickable area of
> checkboxes and radio buttons, otherwise you're limited to clicking a
> fairly small graphic.
You are quite right, it is a standard requirement. But this is just
the first cut...
> 3. The vlist has me a bit puzzled. In the demo, choosing clicking
> the up/down arrows didn't move the thumb. By the way, I really like
> the next-style scrolls, with the arrows stuck together.
I think you mean the vscroll control. My example is poor. Generally,
vscroll is a bit of a dilemma for me. How much do I move the thumb
slider, when the arrow is clicked? Just a pixel and adjust the list
display accordingly? That's not terribly satisfactory with both
relatively short and relatively long lists. So I basically postpone
the decision until the list size is known and then move the list one
line up or down per click. I have experimented with continuous
movement while the rat button remains pressed, but for that I need
better timer resolution than 18 ticks per second, and unfortunately
tick_rate() does not seem to work properly at all in NT dos windows...
> 4. The behavior of the lists is a bit disconcerting. I expected
> clicking the list to set focus on an item, not to choose an item.
> The lack of visible feedback makes me unsure as to which item I've
> actually selected.
I originally had an inverted display there, then removed it when I
used it for the file selector (where it is superfluous) and forgot to
put it back in. Next time.
> 5. It would be nice if the sle changed appearance to show that it
> was in edit mode - perhaps drawing a thick border around the box.
> The I-beam is a bit thin, especially if I have my glasses off.
Changed appearance is a good idea. The cursor is just one pixel wide
xor-ed vertical line, built into my prompt in font.e. I'll change it
to three pixels, because the speed is not of real importance in this
case anyway.
> Btw, associative lists
>
> I'm quite font of associative lists myself, and your implementation
> is typically clever. I had used a similar mechanism in Llama to try
> avoiding the namespace mess, but the overhead of using strings as
> keys turned out to be significant.
That's what I thought too, but when I ran even more complex widgets on
my old 50 MHz 486 for comparison, I did not see any performance
degradation at all.
> I was thinking that, since Euphoria is optimized to append data
> elements, it might be faster to store the keys and values like so:
>
> { key list, value list }
This is exactly what I used for a number of years, as I mentioned in
my previous note. I think I called it 'parallel sequences' scheme.
There is not much in it, but indexing of a 1d sequence is obviously
faster than indexing of a 2d sequence.
> Again, very nice - almost enough to make me go back to the portable
> GUI project.
Don't you even think about it! You have enough on your plate as it is.
Thanks, David.
Irv wrote:
> Nice job - especially the selector(s).
> It would be good to add an event handler, which could, among other
> things, re-order the 'pile' so as to bring a clicked-upon widget to
> the foreground.
Thank you very much too, Irv.
I thought about it and even played with it. As it turns out, it is
fairly simple to implement, but eventually I decided to keep it as
simple as possible, initially, and wait for the feedback - if any.
Generally, if no one else is going to use it, I do not have to worry
about proper documentation, easy formats, updates, additional widgets
and comments, etc. So it's up to you guys...
jiri
|
Not Categorized, Please Help
|
|
