Hi, Well, I just subclassed the ScrollTable and ProgressBar for now - I remove the widgets from the collection and add them in the onLoad and remove in onUnload, that works nicely. We have to release multiple applications the coming days so not much time to create a patch or even switch to a new release of GWT-incubator.
I don't like the idea of using a Timer or even a WindowResizeListener in widgets... but I don't see any other way to getting some feedback when something changes in the DOM. It's a shame actually that DOM does not have such a native event - maybe we should propose something to w3c and hope that it gets included in our lifetime ? In case of the ProgressBar widget, I actually had an implementation that did not need to recalc the div blocks. It even supported a xor effect on the text showing the percentage (the incubator switches style when reaching 50%). But I threw it away when I got my hands on the incubator (less maintenance for me). I also had something implemented where all widgets in my DOM hierarchy would call a layout method when one of the other widgets resized somehow. But that meant that I had to implement this support in every widget I had in the DOM tree. And it was triggered every time a widget was added or removed. In a big UI that consumed a lot of CPU cycles and in many cases no resizing was needed. I switched to using the ResizableWidget approach and the performance is a lot better (and the code cleaner). I am not in favour of removing the timer. Components that need to know should find out automatically. In small projects you can easily manage this, but in larger organisations many bugs will arise because developers do not care about these fine details when developing. Also, we want to reuse busines UI objects in other UIs and then we need to expose these resizing problems to higher level UI components. Some of the components of GWT have a tendency to let the app developer handle the complexity and in many cases that can create very dangerous dependencies in code (spaghetti code we call it). The TabPanel is such a component: it attaches all children widgets right away, even when not in the visible tab. If you have a widget that depends on size calculations of the parent component then it breaks because the size will be 0. There is a solution ofcourse, to lazyly add the panel containing the widget - but that is more work for a developer that just wants to reuse an existing UI component. David On Thu, Mar 5, 2009 at 2:46 PM, Joel Webber 𐑯(ټ)𐑥 <[email protected]> wrote: > [cc'ing John, who IIRC wrote the resizable widgets] > > That does indeed sound like a bad thing. At the very least, it would be > important to get that list cleared out so that it's not growing without > bound. And yes, onLoad/onUnload would be the right time to do it. > > I'm also curious about your usage of these widgets. Are they used in such a > way that it would be relatively easy to hook the window's resize event and > iterate over them to give them a chance to resize? And do you think that > would be sufficient to capture the times when they actually *need* to > resize? I ask because I've always been slightly uncomfortable with the idea > of resizing based upon a timer, but there's no better way to do so in the > general case -- because any change to the DOM, text, CSS, or what have you > can, in theory, cause a widget to resize. But I'm wondering if providing > somewhat more limited semantics (along the lines of "this widget needs to be > told when its size changes, but it's up to the application to do so") would > allow us to get rid of the timers altogether. > > Cheers, > joel. > > On Thu, Mar 5, 2009 at 3:33 AM, stuckagain <[email protected]> wrote: > >> >> GWT Incubator People, >> >> Since I don't know where to start a discussion on design decisions for >> the incubator, I'll do it here. >> >> There is a fundamental problem in incubator that leads to memory leaks >> and reduced performance. >> >> For example the ScrollTable (now in AbstractScrollTable) and >> ProgressBar add themselfs to the ResizableWidgetCollection in the >> constructor. >> >> The problem is that they are NEVER removed. >> >> Would'nt it be beter that these kind of components only add to the >> ResizableWidgetCollection in the onLoad and remove automatically in >> the onUnload ? >> >> We are using Progress Bars in Tables and many ScrollTables as well. >> Every time that table is reconstructed, the memory usage increases. >> After some time we also notice that the CPU usage goes up even when >> the user is not doing anything. >> >> David >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
