Stores WaitWhile Interface
Locked
 
|
Hi,
Store has some interesting waitWhile:
UI feateres.
Does anyone know where this is hidden in the system
and give me some hints how to use it ?
Regards,
@Maarten,
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Stores WaitWhile Interface
|
|
On 07.03.2010 12:22, Maarten MOSTERT wrote:
Do you mean the loading pop-overs? In that case, (in an ApplicationModel) you do: Store.StoreProgressOverlay subsume: self builder window while: myWorkBlock then in myWorkBlock, you announce progress like this: Store.StoreWorkActivity notifications announce: (Store.Loading for: ((Store.Record new) name: mainString; version: inBracesString; yourself)). Obviously this was made specifically for Store, tbh I'd appreciate if it were abstracted in 7.8, as I've also found it a nice improvement over other progress indicators previously used in the app, where a good remaining/total progress is hard to calculate :) Cheers, Henry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Stores WaitWhile Interface
|
|
Thanks this works perfectly.
@+Maarten,
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Stores WaitWhile Interface
|
|
In reply to this post by Henrik Sperre Johansen
On Mar 7, 2010, at 5:20 AM, Henrik Sperre Johansen wrote: > Obviously this was made specifically for Store, tbh I'd appreciate > if it were abstracted in 7.8, as I've also found it a nice > improvement over other progress indicators previously used in the > app, where a good remaining/total progress is hard to calculate :) This was mentioned internally as well the other day, so I'll take I crack at a public response. The short answer is No, but kind of Yes (not necessarily 7.8, but hopefully sometime). The reason there won't be a general purpose one of these is in the first line of your text: "...this was made specifically for Store." This is so true. I spent a bit of time, designing and iterating to make this just right for Store. Whether I actually succeeded or not isn't really the point, but rather that an attempt to hone it for the problem at hand was made. UI's tell stories, and providing good feedback is a part of the story they tell. In the case of the Store overlay, it has two independent text parts (the target component, and the verb), with placement and colors specifically chosen to try and keep them in proper relationship to each other. The spinner is designed to spin under certain conditions and to actually pause in others. The placement at the top and darkening of the underlying window was specific, it had to be done in such a way that it could fit on top of any IDE window (whereas some UIs might be able to provide more concise placement and offsetting techniques to make them fit better with the host app). All these things make it an ill fit for a general purpose abstraction. Any "one size fits all" progress indicator is doomed to be subpar, because it won't dovetail with the host application well. Where's the Yes then? What it should be easy to do, is to quickly/easily compose feedback visualization. And those pieces that we might compose them from ARE candidates for general purpose abstraction. Here's a couple of those components: Overlay Technique - The process where we smack a full window view over what's there to screen out other UI events, and to make it so you can easily program the composition of them. We're trying to simplify the whole wrapper/ container/component linkage so that snapping views into and out of the view tree is simpler. We're getting there. But it's tricky/slow going because of the immense backwards compatibility pressure. Easy Composability Snapping views together, is made easier by the StoreProgressOverlay superclass (Panel). Panel's a work in progress, but it does make the kind of thing where we consume the whole view and have the top, but inset, edge aligned rectangle for the progress information pretty easy. Most of the newer widgets in the IDE (BundleContentsView, PrerequisiteExplorerView, the various StoreProgress components), are all done with Panels. Easy Animation - The ProcessHealthView blatantly ripped off from ExtraActivity. When I developed it, I loaded EA, made it do what I want, then cloned the behavior that I needed over, to avoid conflicts/dependency on EA. At some point, we really need to implement/integrate something that provides what EA does. Notification When doing feedback, you have to instrument your process somehow. Sometimes you can push the information. Sometimes you only want to make sure there's enough data available to a watching process to determine what it must. In all cases, you want to keep this instrumentation as lightweight as possible. Your instrumentation is basically a violation of separating model from presentation, so you keep it as loosely coupled as possible. Announcements are the preferred way when you are in a position where you'll be "pushing" the instrumentation for consumption. The point is, I'd like it to become easy for any application developer to assemble feedback stuff that is well tuned to the problem at hand in obvious and simple ways. -- Travis Griggs Objologist "You A students, you'll be back soon teaching here with me. You B students, you'll actually go on to be real engineers. You C students, you'll go into management and tell the A and B students what to do." - My Fluid Dynamics Professor whom I have yet to disprove _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |