[1.1] Object>>initialExtent
Locked
 
|
Hi!
I do not have a solution, but Object>>initialExtent was recently deprecated and this causes great usability problem. This deprecation is very valuable for a clean UI separation. However, I have a warning deprecation each time a window is open. The reason stems from the method: SystemWindow>>initialExtent ^ model initialExtent For now, in my image, I suppressed this deprecation. Again, I do not have a clean solution. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [1.1] Object>>initialExtent
|
|
I ran into this as well. I tried to avoid triggering the deprecation,
to see if the model understood initialExtent before sending it and guarding for nil models and things like that. otherwise just dispatching to the default extent, however this is difficult because all objects understand initialExtent! i needed a method respondsToButNotInObject:... at that point I got distracted. it is ugly to do this deep respondsTo: check so I was not sure what the correct way of approaching this deprecation was. I assumed someone had a nice solution when they deprecated it? Mike On Thu, Mar 4, 2010 at 5:49 PM, Alexandre Bergel <[hidden email]> wrote: > Hi! > > I do not have a solution, but Object>>initialExtent was recently > deprecated and this causes great usability problem. This deprecation > is very valuable for a clean UI separation. However, I have a warning > deprecation each time a window is open. The reason stems from the > method: > > SystemWindow>>initialExtent > ^ model initialExtent > > For now, in my image, I suppressed this deprecation. > Again, I do not have a clean solution. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [1.1] Object>>initialExtent
|
|
The user interface or the model should define the initialExtent
I do not understand why 1 initialExtent makes sense. We have to define initialExtent to some model. Stef > I ran into this as well. I tried to avoid triggering the deprecation, > to see if the model understood initialExtent before sending it and > guarding for nil models and things like that. otherwise just > dispatching to the default extent, however this is difficult because > all objects understand initialExtent! i needed a method > respondsToButNotInObject:... at that point I got distracted. it is > ugly to do this deep respondsTo: check so I was not sure what the > correct way of approaching this deprecation was. I assumed someone had > a nice solution when they deprecated it? > > Mike > > On Thu, Mar 4, 2010 at 5:49 PM, Alexandre Bergel <[hidden email]> wrote: >> Hi! >> >> I do not have a solution, but Object>>initialExtent was recently >> deprecated and this causes great usability problem. This deprecation >> is very valuable for a clean UI separation. However, I have a warning >> deprecation each time a window is open. The reason stems from the >> method: >> >> SystemWindow>>initialExtent >> ^ model initialExtent >> >> For now, in my image, I suppressed this deprecation. >> Again, I do not have a clean solution. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [1.1] Object>>initialExtent
|
|
Hi all,
RealEstateAgent already responds to standardWindowExtent and to set an initial extent should be under the responsibility of the window manager (not the model). From the World point of view, it's a layout managing related functionality. So, when a window is added to the world, the World should set an initial extent as well as a position to the window. The world layout manager (maybe RealEstateAgent) could cache this information within a dictionary keyed by the model class. The benefit would be that on re-opening, a window size could be retrieved. I've opened an issue http://code.google.com/p/pharo/issues/detail?id=2111 Cheers Alain Stéphane Ducasse a écrit : > The user interface or the model should define the initialExtent > I do not understand why > 1 initialExtent makes sense. > > We have to define initialExtent to some model. > > Stef > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [1.1] Object>>initialExtent
|
|
In reply to this post by Stéphane Ducasse
On 4 March 2010 21:43, Stéphane Ducasse <[hidden email]> wrote:
> The user interface or the model should define the initialExtent > I do not understand why > 1 initialExtent makes sense. > :) me either. Obviously the problem is not in one who implements that message, but to whom this message should be directed. > We have to define initialExtent to some model. > > Stef > >> I ran into this as well. I tried to avoid triggering the deprecation, >> to see if the model understood initialExtent before sending it and >> guarding for nil models and things like that. otherwise just >> dispatching to the default extent, however this is difficult because >> all objects understand initialExtent! i needed a method >> respondsToButNotInObject:... at that point I got distracted. it is >> ugly to do this deep respondsTo: check so I was not sure what the >> correct way of approaching this deprecation was. I assumed someone had >> a nice solution when they deprecated it? >> >> Mike >> >> On Thu, Mar 4, 2010 at 5:49 PM, Alexandre Bergel <[hidden email]> wrote: >>> Hi! >>> >>> I do not have a solution, but Object>>initialExtent was recently >>> deprecated and this causes great usability problem. This deprecation >>> is very valuable for a clean UI separation. However, I have a warning >>> deprecation each time a window is open. The reason stems from the >>> method: >>> >>> SystemWindow>>initialExtent >>> ^ model initialExtent >>> >>> For now, in my image, I suppressed this deprecation. >>> Again, I do not have a clean solution. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |