-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi.
Where are you manually setting the document state? I found out that I _had_ to do it before calling setDocument()... otherwise I always got a null update manager. Regards, Stefan. On Thursday 18 September 2003 13:12, Philippe Converset wrote: > Thomas, > > I've tried what you were saying on two different files: "mines.svg" and > "anne.svg". It works on the first one without problem, the display > always renders the GVT even if you zoom or resize (although it diverges > from the DOM). As for the second file, no update manager is available > through JSVGCanvas (it's a static document unlike the first one) even if > the document state is manually set to ALWAYS_DYNAMIC. Any idea on how to > retrieve a non null update manager? > > Thanks for your help, > > Philippe > > Thomas DeWeese wrote: > > Philippe Converset wrote: > >> In a previous thread (04/02/2002), it's been said that JSVGComponent > >> could not handle cases where the GVT tree is directly modified (there > >> is no repaint). Is it still the case? If so, then would it be a hard > >> work to add such a feature? The idea behind is to be able to the GVT > >> packages without DOM. > > > > If you want to modify the GVT tree directly you still need to > > go through the UpdateManager runnable queue. It is my belief that > > if you do this the repaint will happen. The real issue is that > > the JSVG* components are built around SVG and they are where dynamic > > changes are currently handled. The JGVTComponent is SVG/DOM > > independent but currently has no UpdateManager (I believe this is what > > Stephane was refering to). As a test make a runnable that changes > > the fill or shape of a shape node directly and add it to the > > UpdateManager's runnable queue on a JSVGCanvas - the > > screen should update (this is what happens indirectly when you > > modify the DOM). > > > > If I am right (and I would be interested in knowing) > > the problem is that you can't use this really since, first > > the DOM is still attached to the GVT and second things might > > get really confused if the DOM and GVT diverge. > > > > So I think the majority of the work in making a dynamic > > GVT component would be moving some pieces from the JSVGComponent > > down into the JGVTComponent (most notably the UpdateManager, > > and the associated repaint infrastructure). In other words this > > would be almost all refactoring of existing code - I would have > > to spend a lot more time looking at class dependencies to > > know exactly how complex the refactoring is. My gut feeling is that > > the refactoring would not be terribly complex and would likely > > improve the structure of the Batik components. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iQEVAwUBP2m2270ge6mq4AL2AQJEZggApnJmvWOEqGR9ezOjhkC1dZzY8j/F6yev LjzQNd+SXIJroxCGW175Yxnniww9SFu2kRO7YH/ZyscWhafsVK0ULwO++A7q2Gif PT+cbTP/dd+8hl5pl85KK3yzHziS8rvnYXx27gusBgKwOuReyFrPfMSUWvQcOdxS tDksrgGEfSM6lS3XrngBvnBKpY0Q7nDZY426vN6jM+VQb/BWiW+ZzpdkpKpdaddU hL9kOou+Z+01R7nom4KrRvXnpeEMeSvIQygdf/v74VcbAiQTiLsNcsZGr4OGolp/ dhqByVwcbvuLR4bsd1utWqTQhgiHtef0gCYwcz6/L+EFJFqcOZpOsA== =CIti -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
