[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: widgets with dynamic-choice
From: |
Stefan Monnier |
Subject: |
Re: widgets with dynamic-choice |
Date: |
Tue, 19 Jul 2016 10:25:26 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
> I think that's easy for the programmers but annoying for the users.
> Responsive UI is important everywhere in Emacs. I am happy to discuss
> the pros and cons of what I'm proposing, I'm not saying it must be done.
> Only that it should not be discarded outright.
Agreed, but if the function takes a month, what can the widget do?
Timeout and then what? A "UI" which tells me "this thing
timed out" is not a "responsive UI". A responsive UI will do something
*useful* in a timely fashion.
You could use an async interface, calling the function with a callback
so the display can be updated incrementally as new elements of the
dynamic choice are encountered. Of course, that still doesn't solve the
case where the next element takes a month to be found.
"Too long computations" are simply bugs in the function and there's
no point trying to detect them in the widget code, IMO: the user will
notice the problem on its own anyway.
> Specifically for this case, interactive dialogs should show something
> within 1-5 seconds or users will assume something is wrong
And rightly so.
> and try to interrupt or move away.
So, not very different from what you'd get by adding a timeout. Hence,
adding a timeout doesn't improve the user's experience. To improve the
user's experience, you need to fix the underlying function so it doesn't
take that long.
BTW, for all the cases I remember where I've wanted a `dynamic-choice'
widget, the computation of the list would be trivial and instantaneous.
SM> In case there's a bug in the function? Yes. Same as when there's a bug
SM> anywhere else. I don't understand why you think this case is different.
> Because currently widgets load instantly from a fixed set (with the one
> exception you mentioned), and with this proposal they can call a
> function. We're adding complexity so I wanted to at least consider the
> effect of it to users in the Customize interface.
Even loading from a fixed set, I've experienced bugs with the
customize UI. This really is no different (and it's even less
different if you consider Emacs as a whole).
> I think `widget-setup' is the right place to add the dynamic fills
> (computation), hooking that into the buffer redisplay hook. The part of
> `widget-*-value-create' that gets and inserts the list of choices from
> :args will need to be factored out so it can be called from
> that hook. WDYT?
The reason why I haven't implemented it myself is because I know next to
nothing about the widget code, so I'm afraid I won't be of much
help here.
Stefan