Progress-bar positioning
Locked
 
|
I just committed a fix that allows SystemProgressMorph to not ignore
the users requested position on the screen. String displayProgress:at:... accepts the position to display the progress, but was ignoring it. The result is that the progress bar is now being displayed where it, traditionally, has been requested to be displayed - at the Sensor's cursorPoint. If that isn't desirable, we'll have to change senders of displayProgress:at:... What I would like is to have a preference; the Display selector #center, #topCenter, #topLeft, bottomCenter, etc. which allows us to specify where we want progress-bar to be displayed. Besides plaing correctness, my motivation for fixing this was I am tired of always having to move the progress-bar out of hte way when the debugger opens behind it. If I specify #topCenter for the (yet unimplemented) preference, then there would be reasonable real-estate to utilize the debugger. - Chris PS - To ensure a smooth update process, I also left behind three now-unused methods. Does anyone remember whether we have a way to "mark" methods for deletion (other than #isThisEverCalled)? |
Re: Progress-bar positioning
|
|
On Sat, 4 Jun 2011, Chris Muller wrote:
> I just committed a fix that allows SystemProgressMorph to not ignore > the users requested position on the screen. String > displayProgress:at:... accepts the position to display the progress, > but was ignoring it. > > The result is that the progress bar is now being displayed where it, > traditionally, has been requested to be displayed - at the Sensor's > cursorPoint. > > If that isn't desirable, we'll have to change senders of displayProgress:at:... > > What I would like is to have a preference; the Display selector > #center, #topCenter, #topLeft, bottomCenter, etc. which allows us to > specify where we want progress-bar to be displayed. > > Besides plaing correctness, my motivation for fixing this was I am > tired of always having to move the progress-bar out of hte way when > the debugger opens behind it. If I specify #topCenter for the (yet > unimplemented) preference, then there would be reasonable real-estate > to utilize the debugger. Which class will implement the preference? DisplayScreen? Levente > > - Chris > > PS - To ensure a smooth update process, I also left behind three > now-unused methods. Does anyone remember whether we have a way to > "mark" methods for deletion (other than #isThisEverCalled)? > > |
|
|
> Which class will implement the preference? DisplayScreen?
Yes, that seems like a very reasonable candidate to me. My only question is, do we want to maintain #cursorPoint as a viable option for displaying progress bar? It seems reasonable to me, but then we would have to either have a case check or implement cursorPoint on DisplayScreen.. |
Re: Progress-bar positioning
|
|
On Tue, 7 Jun 2011, Chris Muller wrote:
>> Which class will implement the preference? DisplayScreen? > > Yes, that seems like a very reasonable candidate to me. My only > question is, do we want to maintain #cursorPoint as a viable option > for displaying progress bar? It seems reasonable to me, but then we > would have to either have a case check or implement cursorPoint on > DisplayScreen.. > Thinking a bit about it I came to the following idea: The preference would be added to ProgressInitiationException. The values of the preference would be symbols, like #cursorPoint, #center, #topCenter, etc. The exception would use UIManager to find out what the symbol means. The value of the preference would be used when no point would be requested (nil value). This way we wouldn't introduce unnecessary dependencies. Ideally one would be able to write things like 'foo' displayProgressAt: #center from: ... Or another helper method using the value of the preference: 'foo' displayProgressFrom: ... This requires a new kind of preference where the user can select it's value from a predefined list. I'm sure this would also be useful in other cases. What do you think? Levente |
|
|
Sorry for the delayed reply. Yes absolutely,
ProgressInitiationException is a better candidate to be responsible for knowing the users preferred location for progress-indication than DisplayScreen. I also like the idea of a helper-method that would be able to simplify the API; e.g., by not requesting an exact Point location for progress bar (by just excluding that argument) and, in that case, falling back to the preference. Requesting an exact point seems like unnecessary flexibility, but since it's already supported by the Morphs we may as well leave it. However, being able to simplify all of those hundred+ senders (however many it is) to not have to repeatedly say, "Display preferredProgressPosition" or whatever is addition-by-subtraction. Excellent! - Chris On Thu, Jun 9, 2011 at 4:31 PM, Levente Uzonyi <[hidden email]> wrote: > On Tue, 7 Jun 2011, Chris Muller wrote: > >>> Which class will implement the preference? DisplayScreen? >> >> Yes, that seems like a very reasonable candidate to me. My only >> question is, do we want to maintain #cursorPoint as a viable option >> for displaying progress bar? It seems reasonable to me, but then we >> would have to either have a case check or implement cursorPoint on >> DisplayScreen.. >> > > Thinking a bit about it I came to the following idea: > The preference would be added to ProgressInitiationException. The values of > the preference would be symbols, like #cursorPoint, #center, #topCenter, > etc. The exception would use UIManager to find out what the symbol means. > The value of the preference would be used when no point would be requested > (nil value). This way we wouldn't introduce unnecessary dependencies. > Ideally one would be able to write things like > 'foo' displayProgressAt: #center from: ... > Or another helper method using the value of the preference: > 'foo' displayProgressFrom: ... > > This requires a new kind of preference where the user can select it's value > from a predefined list. I'm sure this would also be useful in other cases. > > What do you think? > > > Levente > |
|
|
Hi, I spent a little time toward getting our progress-bar back to a
consistent position - as determined by a new preference in ProgressInitiationException. Please let me know if you have any comments on the new Exceptions package. I don't think any new package dependencies were created as a result of this - thanks Levente. We do still have a lot of senders of #displayProgressAt: Sensor cursorPoint from:to:... We should simplify those to allow the new preference to be honored. However, rather than go through all of them and create a bunch of new package versions just for that change, how about we just update them as-we-go; the next time you commit a change to a package, please browse senders of String>>#displayProgressAt:from:to:during:, please remove the first argument (to send String>>#displayProgressFrom:to:during: instead). These packages are now taken care of: Toolbuilder-Kernel Graphics Exceptions because they are the ones I just committed. As other packages are changed, it would be nice if we could make this update.. Thanks, Chris On Sun, Jun 12, 2011 at 1:55 PM, Chris Muller <[hidden email]> wrote: > Sorry for the delayed reply. Yes absolutely, > ProgressInitiationException is a better candidate to be responsible > for knowing the users preferred location for progress-indication than > DisplayScreen. > > I also like the idea of a helper-method that would be able to simplify > the API; e.g., by not requesting an exact Point location for progress > bar (by just excluding that argument) and, in that case, falling back > to the preference. > > Requesting an exact point seems like unnecessary flexibility, but > since it's already supported by the Morphs we may as well leave it. > However, being able to simplify all of those hundred+ senders (however > many it is) to not have to repeatedly say, "Display > preferredProgressPosition" or whatever is addition-by-subtraction. > Excellent! > > - Chris > > > On Thu, Jun 9, 2011 at 4:31 PM, Levente Uzonyi <[hidden email]> wrote: >> On Tue, 7 Jun 2011, Chris Muller wrote: >> >>>> Which class will implement the preference? DisplayScreen? >>> >>> Yes, that seems like a very reasonable candidate to me. My only >>> question is, do we want to maintain #cursorPoint as a viable option >>> for displaying progress bar? It seems reasonable to me, but then we >>> would have to either have a case check or implement cursorPoint on >>> DisplayScreen.. >>> >> >> Thinking a bit about it I came to the following idea: >> The preference would be added to ProgressInitiationException. The values of >> the preference would be symbols, like #cursorPoint, #center, #topCenter, >> etc. The exception would use UIManager to find out what the symbol means. >> The value of the preference would be used when no point would be requested >> (nil value). This way we wouldn't introduce unnecessary dependencies. >> Ideally one would be able to write things like >> 'foo' displayProgressAt: #center from: ... >> Or another helper method using the value of the preference: >> 'foo' displayProgressFrom: ... >> >> This requires a new kind of preference where the user can select it's value >> from a predefined list. I'm sure this would also be useful in other cases. >> >> What do you think? >> >> >> Levente >> > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |