Menu
▾
▴
springframework-rcp-dev — Spring Rich Client developer list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(37) |
Jun
(141) |
Jul
(111) |
Aug
(91) |
Sep
(79) |
Oct
(151) |
Nov
(161) |
Dec
(93) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(40) |
Feb
(60) |
Mar
(43) |
Apr
(90) |
May
(31) |
Jun
(114) |
Jul
(35) |
Aug
(112) |
Sep
(305) |
Oct
(151) |
Nov
(122) |
Dec
(103) |
| 2006 |
Jan
(65) |
Feb
(57) |
Mar
(475) |
Apr
(276) |
May
(482) |
Jun
(134) |
Jul
(127) |
Aug
(188) |
Sep
(271) |
Oct
(220) |
Nov
(74) |
Dec
(41) |
| 2007 |
Jan
(121) |
Feb
(50) |
Mar
(36) |
Apr
(11) |
May
(31) |
Jun
(12) |
Jul
(73) |
Aug
(41) |
Sep
(59) |
Oct
(33) |
Nov
(60) |
Dec
(111) |
| 2008 |
Jan
(139) |
Feb
(49) |
Mar
(87) |
Apr
(43) |
May
(10) |
Jun
(25) |
Jul
(114) |
Aug
(17) |
Sep
(25) |
Oct
(199) |
Nov
(94) |
Dec
(45) |
| 2009 |
Jan
(36) |
Feb
(14) |
Mar
(29) |
Apr
(32) |
May
(49) |
Jun
(18) |
Jul
(68) |
Aug
(34) |
Sep
(34) |
Oct
(11) |
Nov
(10) |
Dec
(14) |
| 2010 |
Jan
(35) |
Feb
(12) |
Mar
(23) |
Apr
(17) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
(10) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(8) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
(5) |
Jun
(1) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(15) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Geoffrey De S. (JIRA) <no...@sp...> - 2008-01-14 13:55:31
|
[ http://jira.springframework.org/browse/RCP-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_29011 ]
Geoffrey De Smet commented on RCP-512:
--------------------------------------
there's a new version of agilejava's plugin on the repo since today (or yesterday):
www.mvnrepository.com
I would be nice to get it generated with "mvn site" (= site phase) and deployed with "mvn site-deploy"
the site could use a link to it (and to the blog too)
> Setup docbook manual in build system
> ------------------------------------
>
> Key: RCP-512
> URL: http://jira.springframework.org/browse/RCP-512
> Project: Spring Framework Rich Client Project
> Issue Type: Task
> Components: Build System
> Affects Versions: 0.2.1
> Reporter: Geoffrey De Smet
> Assignee: Geoffrey De Smet
> Priority: Critical
> Fix For: 1.0.0
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-14 13:39:40
|
[ http://jira.springframework.org/browse/RCP-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_29007 ]
Peter De Bruycker commented on RCP-512:
---------------------------------------
I switched to agilejava. I copied the infrastructure from spring-osgi, and started from there.
it works better than jboss's plugin.
it's possible to generate a pdf, but it's very slow, and a lot of errors are shown.
the html looks fine.
> Setup docbook manual in build system
> ------------------------------------
>
> Key: RCP-512
> URL: http://jira.springframework.org/browse/RCP-512
> Project: Spring Framework Rich Client Project
> Issue Type: Task
> Components: Build System
> Affects Versions: 0.2.1
> Reporter: Geoffrey De Smet
> Assignee: Geoffrey De Smet
> Priority: Critical
> Fix For: 1.0.0
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Stevo S. (JIRA) <no...@sp...> - 2008-01-14 09:03:33
|
Component based Splash Screen API
---------------------------------
Key: RCP-523
URL: http://jira.springframework.org/browse/RCP-523
Project: Spring Framework Rich Client Project
Issue Type: Improvement
Components: Application Framework
Reporter: Stevo Slavic
Priority: Trivial
Please provide component based Splash Screen API and default implementation. Currently implemented SimpleSplashScreen and ProgressSplashScreen do not support easy customization. This improvement should enable one to easily define splash screen components like splash screen image (as on SimpleSplashScreen), splash screen progress bar (as on ProgressSplashScreen), and any other custom component (like an SVG image component, not currently supported in ver. 0.3.0 rev. 1898). For initial discussion on this issue see http://forum.springframework.org/showthread.php?t=48485 forum thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-11 14:09:35
|
SelectField must implement ControlFactory
-----------------------------------------
Key: RCP-522
URL: http://jira.springframework.org/browse/RCP-522
Project: Spring Framework Rich Client Project
Issue Type: Sub-task
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-11 14:03:32
|
[ http://jira.springframework.org/browse/RCP-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-521.
-----------------------------------
Resolution: Fixed
> RefreshableValueHolder: alwaysRefresh parameter not used
> --------------------------------------------------------
>
> Key: RCP-521
> URL: http://jira.springframework.org/browse/RCP-521
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Binding System
> Reporter: Peter De Bruycker
> Assignee: Peter De Bruycker
> Priority: Minor
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-11 14:03:32
|
RefreshableValueHolder: alwaysRefresh parameter not used
--------------------------------------------------------
Key: RCP-521
URL: http://jira.springframework.org/browse/RCP-521
Project: Spring Framework Rich Client Project
Issue Type: Bug
Components: Binding System
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
Priority: Minor
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-11 14:01:31
|
allow "refreshable" list of items
---------------------------------
Key: RCP-520
URL: http://jira.springframework.org/browse/RCP-520
Project: Spring Framework Rich Client Project
Issue Type: Sub-task
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-11 13:59:32
|
[ http://jira.springframework.org/browse/RCP-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker updated RCP-518:
----------------------------------
Summary: configure title and description of selection dialog (was: sest title and description of selection dialog)
> configure title and description of selection dialog
> ---------------------------------------------------
>
> Key: RCP-518
> URL: http://jira.springframework.org/browse/RCP-518
> Project: Spring Framework Rich Client Project
> Issue Type: Sub-task
> Components: Binding System
> Reporter: Peter De Bruycker
> Assignee: Peter De Bruycker
> Priority: Minor
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-11 13:59:31
|
use command framework for buttons
---------------------------------
Key: RCP-519
URL: http://jira.springframework.org/browse/RCP-519
Project: Spring Framework Rich Client Project
Issue Type: Sub-task
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-11 13:59:31
|
sest title and description of selection dialog
----------------------------------------------
Key: RCP-518
URL: http://jira.springframework.org/browse/RCP-518
Project: Spring Framework Rich Client Project
Issue Type: Sub-task
Components: Binding System
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
Priority: Minor
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-11 13:57:33
|
Remove ValueModel dependency on ApplicationServices
---------------------------------------------------
Key: RCP-517
URL: http://jira.springframework.org/browse/RCP-517
Project: Spring Framework Rich Client Project
Issue Type: Improvement
Reporter: Peter De Bruycker
AbstractValueModel depends on ValueChangeDetector to check if it's value changed.
the AbstractValueModel.getValueChangeDetector method gets the registered ValueChangeDetector using ApplicationServicesLocator.services()
I think this introduces a dependency we must avoid, as it means that the ValueModel "framework" cannot be used without an Application object.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-10 06:29:37
|
Allow selection of object in a Form
-----------------------------------
Key: RCP-516
URL: http://jira.springframework.org/browse/RCP-516
Project: Spring Framework Rich Client Project
Issue Type: New Feature
Components: Binding System, Dialog System
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
from forum: http://forum.springframework.org/showthread.php?t=48022
Some code has been checked in, and a short tutorial was written: http://spring-rich.blogspot.com/2008/01/how-to-use-listselectiondialogbinder.html
There's still some work to do:
- use icons on the buttons
- provide a title for the selection dialog
- there's still a bug in the selection dialog somewhere, causing an IndexOutOfBoundsException
- implement your ItemsProvider idea
- create unit tests
- provide a way to set meaningfull descriptions on the dialog
- ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Jan H. (JIRA) <no...@sp...> - 2008-01-08 08:09:33
|
[ http://jira.springframework.org/browse/RCP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Hoskens closed RCP-515.
---------------------------
Resolution: Fixed
fixed in:
http://spring-rich-c.svn.sourceforge.net/spring-rich-c/?rev=1896&view=rev
> SimpleValidationResultsReporter reports wrong message
> -----------------------------------------------------
>
> Key: RCP-515
> URL: http://jira.springframework.org/browse/RCP-515
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Affects Versions: 0.1.0
> Reporter: Jan Hoskens
> Assignee: Jan Hoskens
> Priority: Minor
> Fix For: 1.0.0
>
>
> The implementation of SimpleValidationResultsReporter checks for errors to update the Messagable but then searches for any validationMessage to report.
> As its name suggests, it should just check for messages instead of only errors to correct its behaviour.
> Another issue here is that it doesn't take the severity into account: eg a warning should only be displayed when there are no errors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Jan H. (JIRA) <no...@sp...> - 2008-01-08 08:03:32
|
SimpleValidationResultsReporter reports wrong message
-----------------------------------------------------
Key: RCP-515
URL: http://jira.springframework.org/browse/RCP-515
Project: Spring Framework Rich Client Project
Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Jan Hoskens
Assignee: Jan Hoskens
Priority: Minor
Fix For: 1.0.0
The implementation of SimpleValidationResultsReporter checks for errors to update the Messagable but then searches for any validationMessage to report.
As its name suggests, it should just check for messages instead of only errors to correct its behaviour.
Another issue here is that it doesn't take the severity into account: eg a warning should only be displayed when there are no errors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Jan H. <jh...@sc...> - 2008-01-07 07:42:50
|
I think you see quite clearly. The current implementation does not seem to be easily extensible. You could suggest/implement some enhancements to the class to provide better overriding support. Kind Regards, Jan On Mon, 2008-01-07 at 09:17 +0200, Rogan Dawes wrote: > Hi folks, > > I would like to implement some additional menu items on the > TextComponentPopup menu, that can modify the text in the JTextComponent > in various ways. > > I see that there is an overridable method which *SHOULD* suit my purposes: > > <http://spring-rich-c.svn.sourceforge.net/viewvc/spring-rich-c/trunk/spring-richclient/support/src/main/java/org/springframework/richclient/text/TextComponentPopup.java?view=log> > > protected CommandGroup getEditableCommandGroup() { > CommandGroup editGroup = > getCommandManager().getCommandGroup("textEditMenu"); > if (editGroup == null) { > editGroup = getCommandManager().createCommandGroup( > "textEditMenu", > new Object[] { GlobalCommandIds.UNDO, GlobalCommandIds.REDO, > "separator", GlobalCommandIds.CUT, > GlobalCommandIds.COPY, GlobalCommandIds.PASTE, > "separator", GlobalCommandIds.SELECT_ALL > } > ); > } > return editGroup; > } > > So, in theory, I could just define a "textEditMenu" command group in > commands-context.xml, and have my additional commands show up. However, > I don't see how to get access to the TextComponent in question in my own > commands. The Copy/Paste/etc commands that the TextComponent uses are > all defined as inner classes, and can access the TextComponent in that > way. But how do I get hold of it in my own (non-inner) class? > > Is it some magic about Targetable commands that I am not seeing? > > Thanks > > Rogan > > ------------------------------------------------------------------------- > 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 |
|
From: Rogan D. <li...@da...> - 2008-01-07 07:18:29
|
Hi folks, I would like to implement some additional menu items on the TextComponentPopup menu, that can modify the text in the JTextComponent in various ways. I see that there is an overridable method which *SHOULD* suit my purposes: <http://spring-rich-c.svn.sourceforge.net/viewvc/spring-rich-c/trunk/spring-richclient/support/src/main/java/org/springframework/richclient/text/TextComponentPopup.java?view=log> protected CommandGroup getEditableCommandGroup() { CommandGroup editGroup = getCommandManager().getCommandGroup("textEditMenu"); if (editGroup == null) { editGroup = getCommandManager().createCommandGroup( "textEditMenu", new Object[] { GlobalCommandIds.UNDO, GlobalCommandIds.REDO, "separator", GlobalCommandIds.CUT, GlobalCommandIds.COPY, GlobalCommandIds.PASTE, "separator", GlobalCommandIds.SELECT_ALL } ); } return editGroup; } So, in theory, I could just define a "textEditMenu" command group in commands-context.xml, and have my additional commands show up. However, I don't see how to get access to the TextComponent in question in my own commands. The Copy/Paste/etc commands that the TextComponent uses are all defined as inner classes, and can access the TextComponent in that way. But how do I get hold of it in my own (non-inner) class? Is it some magic about Targetable commands that I am not seeing? Thanks Rogan |
|
From: Jan H. (JIRA) <no...@sp...> - 2008-01-04 19:07:33
|
[ http://jira.springframework.org/browse/RCP-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Hoskens closed RCP-514.
---------------------------
Resolution: Fixed
Default closeAction set:
http://spring-rich-c.svn.sourceforge.net/spring-rich-c/?rev=1891&view=rev
> Set default CloseAction of ApplicationDialog to CloseAction.DISPOSE
> -------------------------------------------------------------------
>
> Key: RCP-514
> URL: http://jira.springframework.org/browse/RCP-514
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Application Framework
> Reporter: Jan Hoskens
> Assignee: Jan Hoskens
> Fix For: 1.0.0
>
>
> The default CloseAction of ApplicationDialog should be CloseAction.DISPOSE to prevent memory-leaks due to unawareness of this feature. Caching of the graphical dialog when using CloseAction.HIDE should be explicitly set when needed.
> As a side note: this behaviour should be well documented.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@sp...> - 2008-01-04 14:51:32
|
[ http://jira.springframework.org/browse/RCP-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-156.
-----------------------------------
Resolution: Fixed
new StatusBar api resolves this issue.
> Status bar more appealing looks
> -------------------------------
>
> Key: RCP-156
> URL: http://jira.springframework.org/browse/RCP-156
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Application Framework
> Environment: NR
> Reporter: Alex Shenyderman
> Assignee: Peter De Bruycker
> Priority: Trivial
> Attachments: EmptyView.java, status-bar-patch.txt
>
>
> I just had a need to use ProgressBar and was surprised at how ugly it looks. Anyway, I cleaned it up a bit and it looks a bit better IMO. So here is the patch
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Jan H. (JIRA) <no...@sp...> - 2008-01-04 11:03:34
|
Set default CloseAction of ApplicationDialog to CloseAction.DISPOSE
-------------------------------------------------------------------
Key: RCP-514
URL: http://jira.springframework.org/browse/RCP-514
Project: Spring Framework Rich Client Project
Issue Type: Improvement
Components: Application Framework
Reporter: Jan Hoskens
Assignee: Jan Hoskens
Fix For: 1.0.0
The default CloseAction of ApplicationDialog should be CloseAction.DISPOSE to prevent memory-leaks due to unawareness of this feature. Caching of the graphical dialog when using CloseAction.HIDE should be explicitly set when needed.
As a side note: this behaviour should be well documented.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
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 |
|
From: Peter De B. <pet...@gm...> - 2008-01-04 07:00:40
|
I updated the StatusBar api. A StatusBar interface has been added, with a default implementation. This makes it easier to create new implementations. regards, Peter |
|
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: 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: Jan H. (JIRA) <no...@sp...> - 2008-01-03 10:11:31
|
[ http://jira.springframework.org/browse/RCP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_28749 ]
Jan Hoskens commented on RCP-439:
---------------------------------
I replaced the BLANK_FACE_DESCRIPTOR.getIcon() with a null to fix the building of the trunk.
> make AbstractCommand.getFaceDescriptor() public
> -----------------------------------------------
>
> Key: RCP-439
> URL: http://jira.springframework.org/browse/RCP-439
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Command System
> Affects Versions: 0.1.0, 0.2.0, 0.2.1
> Reporter: Arne Limburg
> Assignee: Peter De Bruycker
>
> In some situations it is necessary to get displayable informations (like text, icon, ...) from a configured AbstractCommand, i.e. if you want to display a command with a component that does not inherit from AbstractButton.
> There is no possibilty for this by now. AbstractCommand should either implement DescribedElement and VisualizedElement or you should make getFaceDescriptor() public.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Jan H. (JIRA) <no...@sp...> - 2008-01-03 09:47:34
|
[ http://jira.springframework.org/browse/RCP-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Hoskens closed RCP-379.
---------------------------
Assignee: Jan Hoskens
Resolution: Fixed
Fix Version/s: 1.0.0
Specific bugs in petclinic are fixed:
http://spring-rich-c.svn.sourceforge.net/viewvc/spring-rich-c?view=rev&revision=1882
Default closeAction in ApplicationDialog is being discussed on the dev list.
> Memory-leak: Petclinic-Sample blunders in the CloseAction trap
> --------------------------------------------------------------
>
> Key: RCP-379
> URL: http://jira.springframework.org/browse/RCP-379
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Dialog System, Samples
> Affects Versions: 0.1.0
> Reporter: Markus Rogg
> Assignee: Jan Hoskens
> Fix For: 1.0.0
>
>
> The default behavior in SRCP is, that it hiddes the ApplicationDialog (RCP-9). I think this is a trap for the application developers and will easy lead to memory-leaks (e.g. the petclinic sample creates every time the user clicks on a pet a new TitledPageApplicationDialog, but the click on OK only hides (default behavior) the dialog (the NewOwnerWizard reuses the dialog and hasn't this problem)). Maybe it's a solution that the customer must use the constructor with the CloseAction to avoid this memory leak.
> Another memory leak (especially for CloseAction.DISPOSE) is RCP-97. This memory leak holds all ApplicationDialogs (the static CommandFaceDescriptor.BLANK knows the CommandFaceButtonManager (registered as PropertyChangeListener), the CommandFaceButtonManager knows the command and the command (finishCommand and cancelCommand) is an anonymous inner class of the ApplicationDialog.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
406 messages has been excluded from this view by a project administrator.
