Menu
▾
▴
springframework-rcp-dev
|
From: Jan H. <jh...@sc...> - 2008-01-03 08:06:43
|
Hi all, I'm reviewing the CloseAction & ApplicationDialog usage to fix RCP-379. Currently the default action is to hide the dialog. Which is fine if it is reused a lot but not when it's a one-shot dialog. Two questions arise: 1) do we want 'hide' to still be the default behavior? I'm comfortable in having the 'hide' default, but it may lead to memory leaks if it's overlooked (as in petclinic now, stated in RCP-379). We can stress this in the api docs of course (which I would do anyways). 2) do we want to override this default in subclasses like MessageDialog/ConfirmationDialog? Both dialogs are typically small one-shot dialogs which won't suffer from recreating the ui that much as a full application dialog. WDYT? Anyways I'll go on and fix the petclinic memory leaks by explicitly providing the closeAction and documenting this in code (probably using both styles to show the difference) Kind Regards, Jan **** DISCLAIMER **** http://www.schaubroeck.be/maildisclaimer.htm |
|
From: Andy D. <an...@ma...> - 2008-01-04 00:30:33
|
My personal conviction is that we should NOT make 'hide' the default behavior. This does not "fail fast" if it is overlooked, and ultimately leads to memory leaks. If dispose is the default action, then the dialog will "fail faster" (the second time it is used). Jan Hoskens wrote: > Hi all, > > I'm reviewing the CloseAction & ApplicationDialog usage to fix RCP-379. > Currently the default action is to hide the dialog. Which is fine if it > is reused a lot but not when it's a one-shot dialog. > > Two questions arise: > > 1) do we want 'hide' to still be the default behavior? > > I'm comfortable in having the 'hide' default, but it may lead to memory > leaks if it's overlooked (as in petclinic now, stated in RCP-379). We > can stress this in the api docs of course (which I would do anyways). > > 2) do we want to override this default in subclasses like > MessageDialog/ConfirmationDialog? > > Both dialogs are typically small one-shot dialogs which won't suffer > from recreating the ui that much as a full application dialog. > > WDYT? > > Anyways I'll go on and fix the petclinic memory leaks by explicitly > providing the closeAction and documenting this in code (probably using > both styles to show the difference) > > Kind Regards, > Jan > > > **** DISCLAIMER **** > http://www.schaubroeck.be/maildisclaimer.htm > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > . > > |
|
From: Peter De B. <pet...@gm...> - 2008-01-04 05:17:16
|
I agree with Andy. Also, I think it's better to leave optimizations when they're needed, so have the programmer explicitly do some work if he wants to "cache" his dialogs. Peter On 1/4/08, Andy DePue <an...@ma...> wrote: > > My personal conviction is that we should NOT make 'hide' the default > behavior. This does not "fail fast" if it is overlooked, and ultimately > leads to memory leaks. If dispose is the default action, then the > dialog will "fail faster" (the second time it is used). > > Jan Hoskens wrote: > > Hi all, > > > > I'm reviewing the CloseAction & ApplicationDialog usage to fix RCP-379. > > Currently the default action is to hide the dialog. Which is fine if it > > is reused a lot but not when it's a one-shot dialog. > > > > Two questions arise: > > > > 1) do we want 'hide' to still be the default behavior? > > > > I'm comfortable in having the 'hide' default, but it may lead to memory > > leaks if it's overlooked (as in petclinic now, stated in RCP-379). We > > can stress this in the api docs of course (which I would do anyways). > > > > 2) do we want to override this default in subclasses like > > MessageDialog/ConfirmationDialog? > > > > Both dialogs are typically small one-shot dialogs which won't suffer > > from recreating the ui that much as a full application dialog. > > > > WDYT? > > > > Anyways I'll go on and fix the petclinic memory leaks by explicitly > > providing the closeAction and documenting this in code (probably using > > both styles to show the difference) > > > > Kind Regards, > > Jan > > > > > > **** DISCLAIMER **** > > http://www.schaubroeck.be/maildisclaimer.htm > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Springframework-rcp-dev mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > . > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > |
|
From: Jan H. <jh...@sc...> - 2008-01-04 07:40:51
|
So we got change default to DISPOSE +1 from me +1 from andy +1 from peter I guess that's a go on that one. I'll create an issue to make clear that this is an important change (and it will end up in the release notes) and will stress this in the docs. Kind Regards, Jan On Fri, 2008-01-04 at 06:16 +0100, Peter De Bruycker wrote: > I agree with Andy. > > Also, I think it's better to leave optimizations when they're needed, > so have the programmer explicitly do some work if he wants to "cache" > his dialogs. > > Peter > > > On 1/4/08, Andy DePue <an...@ma...> wrote: > My personal conviction is that we should NOT make 'hide' the > default > behavior. This does not "fail fast" if it is overlooked, and > ultimately > leads to memory leaks. If dispose is the default action, then > the > dialog will "fail faster" (the second time it is used). > > Jan Hoskens wrote: > > Hi all, > > > > I'm reviewing the CloseAction & ApplicationDialog usage to > fix RCP-379. > > Currently the default action is to hide the dialog. Which is > fine if it > > is reused a lot but not when it's a one-shot dialog. > > > > Two questions arise: > > > > 1) do we want 'hide' to still be the default behavior? > > > > I'm comfortable in having the 'hide' default, but it may > lead to memory > > leaks if it's overlooked (as in petclinic now, stated in > RCP-379). We > > can stress this in the api docs of course (which I would do > anyways). > > > > 2) do we want to override this default in subclasses like > > MessageDialog/ConfirmationDialog? > > > > Both dialogs are typically small one-shot dialogs which > won't suffer > > from recreating the ui that much as a full application > dialog. > > > > WDYT? > > > > Anyways I'll go on and fix the petclinic memory leaks by > explicitly > > providing the closeAction and documenting this in code > (probably using > > both styles to show the difference) > > > > Kind Regards, > > Jan > > > > > > **** DISCLAIMER **** > > http://www.schaubroeck.be/maildisclaimer.htm > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Springframework-rcp-dev mailing list > > Spr...@li... > > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > . > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ Springframework-rcp-dev mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev **** DISCLAIMER **** http://www.schaubroeck.be/maildisclaimer.htm |
Thanks for helping keep SourceForge clean.
X