I wonder what the best way might be to save a dynamic window layout's
current sizes. I have a resizing splitter and want to query and later restore its position (when loading a file). Is there a standard method for this? Thanks, Andre |
Andre:
Possibly you could go nuts and try to do what the UIPainter does i.e. construct a literal spec from a target component tree i.e. the app component tree and then persist to a file , when opening again you check if you have a file and build your fullSpec based on the file. See: UIPainter>>>extractFullSpec it would be interesting to have the capability of extracting the a fullSpec from any applicationModel and not just UIPainter. A quick look and we find: UIPainter>>> builderComponentWrappers ^builder composite components select: [:each | each isKindOf: SpecWrapper] which is called down the line from #extractFullSpec I really have not taken the time but it seems that there may be some hope :) so please let us know what you come up with, it might be quite nice to have on the other hand I guess just persisting the resizingSplitter's position or offset from its container may do you just fine but not as much fun. hth, -Charles On Tue, 11 Jul 2006 18:18:03 -0400, Andre Schnoor <[hidden email]> wrote: > I wonder what the best way might be to save a dynamic window layout's > current sizes. I have a resizing splitter and want to query and later > restore its position (when loading a file). > > Is there a standard method for this? > > Thanks, > Andre -- Charles A. Monteiro http://wiki.nycsmalltalk.org http://www.monteirosfusion.com http://monteirofusion.blogspot.com |
Charles A. Monteiro wrote: > Possibly you could go nuts and try to do what the UIPainter does i.e. > construct a literal spec from a target component tree i.e. the app > component tree and then persist to a file , when opening again you > check if you have a file and build your fullSpec based on the file. Although the idea looks interesting, that'll be too much of an effort. > so please let us know what you come up with, it might be quite nice to > have I will. > > on the other hand I guess just persisting the resizingSplitter's > position or offset from its container may do you just fine but not as > much fun. That seems to be a more rewarding direction. The problem is not so much how to _get_ the current sizes, it is rather how to _restore_ them on load. Will just sending #bounds: to the splitter also re-arrange the other views automatically? Well, I'll see. Regards, Andre |
Andre Schnoor wrote:
>> on the other hand I guess just persisting the resizingSplitter's >> position or offset from its container may do you just fine but not as >> much fun. > > > That seems to be a more rewarding direction. The problem is not so much > how to _get_ the current sizes, it is rather how to _restore_ them on > load. Will just sending #bounds: to the splitter also re-arrange the > other views automatically? Well, I'll see. Well, we have just that although we use it when spawning windows or tabs, but it should work as well when opening the window. I am not sure if it will work in postBuild but it will definitely work in postOpen. There are basically two methods in ResizingSplitterView: #actualPosition and #moveTo:. The first one returns splitter's current position as a point where one of the coordinates is always zero (horizontal vs. vertical). Examples: splitter moveTo: splitter actualPosition "moves splitter to its current position (effectively does nothing)" splitter moveTo: 0@0 "moves splitter to the left (top)." For details see attached package with these methods and some comments. Ladislav Lenart <?xml version="1.0"?> <st-source> <time-stamp>From VisualWorks®, 7.4 of 5. prosinec 2005 on 18. Äervenec 2006 at 9:41:56</time-stamp> <!-- Package ResizingSplitterView moveTo(1.1,Petr Skala)* --> <component-property> <name>ResizingSplitterView moveTo</name> <type>package</type> <property>packageName</property> <value>'ResizingSplitterView moveTo'</value> </component-property> <component-property> <name>ResizingSplitterView moveTo</name> <type>package</type> <property>fractalCreator</property> <value>'fractal'</value> </component-property> <component-property> <name>ResizingSplitterView moveTo</name> <type>package</type> <property>comment</property> <value>'ResizingSplitterView moveTo This package adds two methods to ResizingSplitterView: #moveTo: and #actualPosition. #actualPosition returns splitter''s current position and #moveTo: is used to programmaticaly move splitter to specified position. It is strange that splitter itself does not have this quite natural behavior. Actual position is based on center of the splitter''s bounds within its container. This result is then multiplied by axis so one of the coordinates is always 0. In the case of error, 0@0 is returned. '</value> </component-property> <methods> <class-id>UI.ResizingSplitterView</class-id> <category>sizing / moving</category> <body package="ResizingSplitterView moveTo" selector="moveFromBottomTo:">moveFromBottomTo: aPoint | widget | widget := self specWrapper. widget ifNil: [^self]. self moveTo: widget container bounds extent - aPoint.</body> <body package="ResizingSplitterView moveTo" selector="moveTo:">moveTo: aPoint self moveBy: self axis * aPoint - self actualPosition.</body> </methods> <methods> <class-id>UI.ResizingSplitterView</class-id> <category>accessing</category> <body package="ResizingSplitterView moveTo" selector="actualPosition"> actualPosition | widget layout rectangle | widget := self specWrapper. widget isNil ifTrue: [^0@0]. (widget component isKindOf: LayoutWrapper) ifFalse: [^0@0]. layout := self layoutFor: widget. rectangle := "Procentual layout is used to calculate splitter's absolute bounds within its container." layout rectangleRelativeTo: widget container bounds preferred: widget container preferredBounds. ^rectangle center * self axis. "Center of this bounds multiplied by the sign (horizontal vs. vertical splitter) is the current splitter position." </body> </methods> </st-source> |
Thank you, Ladislav!
that's a perfect solution. I added it to my generic application window state management. BTW: It works in a #postBuild: context, i.e. the window need not to be open. Andre |
Free forum by Nabble | Edit this page |