Re: Abeille Forms Designer in use
|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Abeille Forms Designer in use
by George Talev
::
Rate this Message:
viegs@... wrote: Hi George,Thank you all for your work on the Abeille project! And that you keep it LGPL-ed!! We too :) I think in the short term we could work together on some collaberative code review.Why not.
Happy to hear that the product is being enhanced further. It is OK for me if our changes are applied after Math's. Most of our changes are in the direction of enabling Abeille to be run as a part of another program, not as a standalone program, so I hope that our and Math's work does not overlap :) To give you the basic idea, I will write some more info here about what we did with Abeille. There is an application that is part of the project we are working on, and this application needs the ability to allow users to create forms using our custom Swing components, together with editing and defining many other things, specific for the project. We also needed to have the form designer to be controlled by our application. We tried and liked Abeille as a standalone application and decided to try to make it integration-friendly, so it can be controlled programically from outside. Additionally, we implemented enhancements and fixes that we believe are suitable for the program, no matter if used as a standalone app or as part of another app. So we implemented things like: - "revert to default" - a pop-up-menu command in the Properties editor, which undoes to changes to the selected property by setting it the value taken from the same property of a newly constructed [for that purpose] bean object. - we added a new button in the Border editing window - "Custom border". This opens a new window where the user can type the FQN of a border class and there is the Abeille's Property editor in this window so the user can load and edit the props of the a border not listed in Abeille's default implementation. Well, the field for the border class name must be an editable combo that remembers recent entries.... but that will be added later :) - we added functionality that allows the main application (the one that uses Abeille internally) to hide menu items and menus. When the Abeille is opened as a part of another program, commands like "Close Project", "New Form", "Close Form", "Exit" etc might be unwanted. - there is a flag added, FormDesignerUtils.set/isIntegrated(). When set to 'true' by the main application, Abeille's code won't call "System.exit()' when its frame is closed. - we added functionality which allows the main application to feed Abeille with the XML of the forms and also to read back the XML of the edited forms. This way the main application takes the control of loading and saving the forms. - enhancement that allows the main application to add custom beans to the components palette in runtime. So we don't need to ask the user to add our special components to the palette by herself, neither we are forced to copy some Abeille configuration files to user's computer. - we made changes in the Java code generation routine and the XML serialization routine, because Abeille used to add unnecessary filler components to design gird cells, making it impossible to hide some component in the form in runtime and to let the layout manager to hide the whole row (in case that the row appears to be without other "visible" components).The explanation of this might be really unclear in this email, but anyway later we will give you very detailed information about what and why we've changed. - Java code generation routine didn't generate the code for the constraint Insets. This is now implemented. - added support for custom bean components which are containers (e.g. JPanel ancestors). Abeille needs such custom beans to be wrapped in a GridView. - Changed the visibility of some methods, added new methods that give the main application access to some Abeille internals, so they can be used from the main application. E.g. we needed to add new tab in the Properties editor panel. The idea is that we can't make this tab part of the original Abeille project, since it is very specific for our project and no one else will be interested in it. So we had to give our project access to some Abeille components and panels. - an interface is added (DescriptorSorter) which purpose is to be implemented by the main application, set by calling the appropriate Abeille (new) method and then the Properties editor calls sort() method of that object. That way the main application can set custom sorting for the properties. (e.g. we needed special sort order for the properties for some of our custom beans). - changed the way the Abeille looks for bean icons. If the bean class provides icons, Abeille will now use them in the palette. - visibility of JTable w/o rows - when the JTable has no rows, its height is 0. There was code in com.jeta.forms.gui.form.GridComponent.isShowing() that assumed that if the component's size is 0, then it is not showing. Well, for JTable components it is not correct - it breaks the painting of the table in runtime, namely - the table header does not repaint immediately when the user resizes the columns or reorders them. This happens only if in runtime the form is deserialized from Abeille's XML format. If you use generated Java-code for the form there is no problem, because GridComponent class does not take place then. (There is an issue in the project tracker about it, afair). - The Property editor now remembers the selected property when the user clicks on components in the design grid. So if you select e.g. the "background" property and you start clicking on different beans, the selection stays to "background" property in the Properties panel, as long the property exists for the clicked bean. - some bug fixes.. - I might be forgetting something.... We were thinking about implementing multiple selection of beans in the design grid.... but this appears to be a change that requires a lot of code to be changed and rewritten. So we left that idea (actually, for our needs it appears to be a rare case that we need to select several components together...). We try to consider the changes we make in the Abeille source code so that: - if the changes are related to the need to control Abeille from our application (e.g. the ability to hide menu commands), we try to make them so they appear to be useful for other people who would try to use Abeille from their own applications. And also to make them in such way so they don't affect Abeille when it is run as a standalone application. - if the changes are actually some enhancements, we try to make them to be useful for other Abeille users also (e.g. Reset To Default in Property Editor, remembering the last selected property and so on). We hope we succeed in that aspect so far... - if we fix issues that we think are bugs... well, we hope we managed to explore them really well and we didn't actually made other things worse with our fixes ;) But that can be verified by the code review some day. We have a lot more things related to Abeille in our project, e.g. custom property editors, custom components and so on, but these are all implemented as part of our project source. Whenever we have to, our classes extend Abeille's classes or implement Abeille's interfaces, so we fit the abstraction that Abeille expects. In that case you can update your local working copy against his most recent additions once finalized and then after code review on my end we can proceed to integrate your changes into the Abeille codebase.We didn't checkout the sources from the CVS, we actually downloaded this file: https://abeille.dev.java.net/files/documents/2703/57508/abeille_src_2_0.zip Then we placed the source in our own CVS repository. I had no choice but picking up the source that is marked as "stable". For the project that we develop I should ensure that this condition is met as much as possible - external libraries and programs that we use must be stable releases, no beta or milestones or whatever, unless really really necessary. And I wasn't sure how to checkout the "stable" branch/tag from the Abeille's module in the CVS repo. This is all mainly up to you... Still it is probably better if the the module structure does not become too complex and overloaded with branches/tags... We will need to get to this in fairly short order. When I inherited the project from Jeff there was only trunk from which to work from and coding changes have been managable and more linear in fashion. I hope that our intrusion into your project will not lead to too many difficulties for you :):):):):):) I do not insist about committing our changes in Abeille's CVS immediately. Probably I can just send you Abeille's changed source files so you can diff them against 2.0 release and see what we have changed. Or we can use another approach so you can make a review of our modifications, e.g. a patch file(s).... How do you think? The orthodox Easter holidays start here in Bulgaria followed by other national holidays and I will have a long 10 days vacation, till May 6th incl. Still, I usually check and respond to emails even when in vacation, but please excuse in advance any possible delays in my replies. And don't hesitate to ask about whatever you are interested in. Greetings, George
|
|
|
Re: Abeille Forms Designer in use
by Todd Viegut
::
Rate this Message:
George,
Fantastic work!! I'm excited to integrate your additions to the project...and appreciate you initiating to do so. This will allow them to be maintained in future releases and will benefit both your product and the AFD community as a whole. Finally...I believe we'll plan to role such changes into a new 3.0 release of Abeille given the breadth of them. With willingness such as yours to contribute to Abeille we most definitly will keep it LGPLed. Let's talk more... Kind Regards, ~Todd -----Original Message----- From: George Talev <geo@...> To: viegs@... Cc: dev@... Sent: Fri, 25 Apr 2008 12:51 pm Subject: Re: Abeille Forms Designer in use Hi Todd, thanks for your reply!
viegs@... wrote: Hi George,Thank you all for your work on the Abeille project! And that you keep it LGPL-ed!! We too :) I think in the short term we could work together on some collaberative code review.Why not.
Happy to hear that the product is being enhanced further. It is OK for me if our changes are applied after Math's. Most of our changes are in the direction of enabling Abeille to be run as a part of another program, not as a standalone program, so I hope that our and Math's work does not overlap :) To give you the basic idea, I will write some more info here about what we did with Abeille. There is an application that is part of the project we are working on, and this application needs the ability to allow users to create forms using our custom Swing components, together with editing and defining many other things, specific for the project. We also needed to have the form designer to be controlled by our application. We tried and liked Abeille as a standalone application and decided to try to make it integration-friendly, so it can be controlled programically from outside. Additionally, we implemented enhancements and fixes that we believe are suitable for the program, no matter if used as a standalone app or as part of another app. So we implemented things like: - "revert to default" - a pop-up-menu command in the Properties editor, which undoes to changes to the selected property by setting it the value taken from the same property of a newly constructed [for that purpose] bean object. - we added a new button in the Border editing window - "Custom border". This opens a new window where the user can type the FQN of a border class and there is the Abeille's Property editor in this window so the user can load and edit the props of the a border not listed in Abeille's default implementation. Well, the field for the border class name must be an editable combo that remembers recent entries.... but that will be added later :) - we added functionality that allows the main application (the one that uses Abeille internally) to hide menu items and menus. When the Abeille is opened as a part of another program, commands like "Close Project", "New Form", "Close Form", "Exit" etc might be unwanted. - there is a flag added, FormDesignerUtils.set/isIntegrated(). When set to 'true' by the main application, Abeille's code won't call "System.exit()' when its frame is closed. - we added functionality which allows the main application to feed Abeille with the XML of the forms and also to read back the XML of the edited forms. This way the main application takes the control of loading and saving the forms. - enhancement that allows the main application to add custom beans to the components palette in runtime. So we don't need to ask the user to add our special components to the palette by herself, neither we are forced to copy some Abeille configuration files to user's computer. - we made changes in the Java code generation routine and the XML serialization routine, because Abeille used to add unnecessary filler components to design gird cells, making it impossible to hide some component in the form in runtime and to let the layout manager to hide the whole row (in case that the row appears to be without other "visible" components).The explanation of this might be really unclear in this email, but anyway later we will give you very detailed information about what and why we've changed. - Java code generation routine didn't generate the code for the constraint Insets. This is now implemented. - added support for custom bean components which are containers (e.g. JPanel ancestors). Abeille needs such custom beans to be wrapped in a GridView. - Changed the visibility of some methods, added new methods that give the main application access to some Abeille internals, so they can be used from the main application. E.g. we needed to add new tab in the Properties editor panel. The idea is that we can't make this tab part of the original Abeille project, since it is very specific for our project and no one else will be interested in it. So we had to give our project access to some Abeille components and panels. - an interface is added (DescriptorSorter) which purpose is to be implemented by the main application, set by calling the appropriate Abeille (new) method and then the Properties editor calls sort() method of that object. That way the main application can set custom sorting for the properties. (e.g. we needed special sort order for the properties for some of our custom beans). - changed the way the Abeille looks for bean icons. If the bean class provides icons, Abeille will now use them in the palette. - visibility of JTable w/o rows - when the JTable has no rows, its height is 0. There was code in com.jeta.forms.gui.form.GridComponent.isShowing() that assumed that if the component's size is 0, then it is not showing. Well, for JTable components it is not correct - it breaks the painting of the table in runtime, namely - the table header does not repaint immediately when the user resizes the columns or reorders them. This happens only if in runtime the form is deserialized from Abeille's XML format. If you use generated Java-code for the form there is no problem, because GridComponent class does not take place then. (There is an issue in the project tracker about it, afair). - The Property editor now remembers the selected property when the user clicks on components in the design grid. So if you select e.g. the "background" property and you start clicking on different beans, the selection stays to "background" property in the Properties panel, as long the property exists for the clicked bean. - some bug fixes.. - I might be forgetting something.... We were thinking about implementing multiple selection of beans in the design grid.... but this appears to be a change that requires a lot of code to be changed and rewritten. So we left that idea (actually, for our needs it appears to be a rare case that we need to select several components together...). We try to consider the changes we make in the Abeille source code so that: - if the changes are related to the need to control Abeille from our application (e.g. the ability to hide menu commands), we try to make them so they appear to be useful for other people who would try to use Abeille from their own applications. And also to make them in such way so they don't affect Abeille when it is run as a standalone application. - if the changes are actually some enhancements, we try to make them to be useful for other Abeille users also (e.g. Reset To Default in Property Editor, remembering the last selected property and so on). We hope we succeed in that aspect so far... - if we fix issues that we think are bugs... well, we hope we managed to explore them really well and we didn't actually made other things worse with our fixes ;) But that can be verified by the code review some day. We have a lot more things related to Abeille in our project, e.g. custom property editors, custom components and so on, but these are all implemented as part of our project source. Whenever we have to, our classes extend Abeille's classes or implement Abeille's interfaces, so we fit the abstraction that Abeille expects. In that case you can update your local working copy against his most recent additions once finalized and then after code review on my end we can proceed to integrate your changes into the Abeille codebase.We didn't checkout the sources from the CVS, we actually downloaded this file: https://abeille.dev.java.net/files/documents/2703/57508/abeille_src_2_0.zip Then we placed the source in our own CVS repository. I had no choice but picking up the source that is marked as "stable". For the project that we develop I should ensure that this condition is met as much as possible - external libraries and programs that we use must be stable releases, no beta or milestones or whatever, unless really really necessary. And I wasn't sure how to checkout the "stable" branch/tag from the Abeille's module in the CVS repo. This is all mainly up to you... Still it is probably better if the the module structure does not become too complex and overloaded with branches/tags... We will need to get to this in fairly short order. When I inherited the project from Jeff there was only trunk from which to work from and coding changes have been managable and more linear in fashion. I hope that our intrusion into your project will not lead to too many difficulties for you :):):):):):) I do not insist about committing our changes in Abeille's CVS immediately. Probably I can just send you Abeille's changed source files so you can diff them against 2.0 release and see what we have changed. Or we can use another approach so you can make a review of our modifications, e.g. a patch file(s).... How do you think? The orthodox Easter holidays start here in Bulgaria followed by other national holidays and I will have a long 10 days vacation, till May 6th incl. Still, I usually check and respond to emails even when in vacation, but please excuse in advance any possible delays in my replies. And don't hesitate to ask about whatever you are interested in. Greetings, George
Plan your next roadtrip with MapQuest.com: America's #1 Mapping Site. |
|
|
Re: Abeille Forms Designer in use
by Todd Viegut
::
Rate this Message:
George,
I'd like to discuss this with Math as he has offered to put a little bit of time into a future branching/trunk strategy for Abeille. He has a strong background I believe in this area so I think he will have some input to add to this conversation. Additionally, if you are interested at all....I'd be great to see (for your benefit) how you might proceed with your future development efforts against a stable branch in the projects CVS repository. This then could easily be merged back into trunk or main when you hit personal milestones on your dev team. In summarize, I'd be more than willing to be flexible and work out a mutually beneficial plan if you are comfortable in doing so. Cheers and have an excellent Easter holidy! ~Todd -----Original Message----- From: George Talev <geo@...> To: viegs@... Cc: dev@... Sent: Fri, 25 Apr 2008 12:51 pm Subject: Re: Abeille Forms Designer in use Hi Todd, thanks for your reply!
viegs@... wrote: Hi George,Thank you all for your work on the Abeille project! And that you keep it LGPL-ed!! We too :) I think in the short term we could work together on some collaberative code review.Why not.
Happy to hear that the product is being enhanced further. It is OK for me if our changes are applied after Math's. Most of our changes are in the direction of enabling Abeille to be run as a part of another program, not as a standalone program, so I hope that our and Math's work does not overlap :) To give you the basic idea, I will write some more info here about what we did with Abeille. There is an application that is part of the project we are working on, and this application needs the ability to allow users to create forms using our custom Swing components, together with editing and defining many other things, specific for the project. We also needed to have the form designer to be controlled by our application. We tried and liked Abeille as a standalone application and decided to try to make it integration-friendly, so it can be controlled programically from outside. Additionally, we implemented enhancements and fixes that we believe are suitable for the program, no matter if used as a standalone app or as part of another app. So we implemented things like: - "revert to default" - a pop-up-menu command in the Properties editor, which undoes to changes to the selected property by setting it the value taken from the same property of a newly constructed [for that purpose] bean object. - we added a new button in the Border editing window - "Custom border". This opens a new window where the user can type the FQN of a border class and there is the Abeille's Property editor in this window so the user can load and edit the props of the a border not listed in Abeille's default implementation. Well, the field for the border class name must be an editable combo that remembers recent entries.... but that will be added later :) - we added functionality that allows the main application (the one that uses Abeille internally) to hide menu items and menus. When the Abeille is opened as a part of another program, commands like "Close Project", "New Form", "Close Form", "Exit" etc might be unwanted. - there is a flag added, FormDesignerUtils.set/isIntegrated(). When set to 'true' by the main application, Abeille's code won't call "System.exit()' when its frame is closed. - we added functionality which allows the main application to feed Abeille with the XML of the forms and also to read back the XML of the edited forms. This way the main application takes the control of loading and saving the forms. - enhancement that allows the main application to add custom beans to the components palette in runtime. So we don't need to ask the user to add our special components to the palette by herself, neither we are forced to copy some Abeille configuration files to user's computer. - we made changes in the Java code generation routine and the XML serialization routine, because Abeille used to add unnecessary filler components to design gird cells, making it impossible to hide some component in the form in runtime and to let the layout manager to hide the whole row (in case that the row appears to be without other "visible" components).The explanation of this might be really unclear in this email, but anyway later we will give you very detailed information about what and why we've changed. - Java code generation routine didn't generate the code for the constraint Insets. This is now implemented. - added support for custom bean components which are containers (e.g. JPanel ancestors). Abeille needs such custom beans to be wrapped in a GridView. - Changed the visibility of some methods, added new methods that give the main application access to some Abeille internals, so they can be used from the main application. E.g. we needed to add new tab in the Properties editor panel. The idea is that we can't make this tab part of the original Abeille project, since it is very specific for our project and no one else will be interested in it. So we had to give our project access to some Abeille components and panels. - an interface is added (DescriptorSorter) which purpose is to be implemented by the main application, set by calling the appropriate Abeille (new) method and then the Properties editor calls sort() method of that object. That way the main application can set custom sorting for the properties. (e.g. we needed special sort order for the properties for some of our custom beans). - changed the way the Abeille looks for bean icons. If the bean class provides icons, Abeille will now use them in the palette. - visibility of JTable w/o rows - when the JTable has no rows, its height is 0. There was code in com.jeta.forms.gui.form.GridComponent.isShowing() that assumed that if the component's size is 0, then it is not showing. Well, for JTable components it is not correct - it breaks the painting of the table in runtime, namely - the table header does not repaint immediately when the user resizes the columns or reorders them. This happens only if in runtime the form is deserialized from Abeille's XML format. If you use generated Java-code for the form there is no problem, because GridComponent class does not take place then. (There is an issue in the project tracker about it, afair). - The Property editor now remembers the selected property when the user clicks on components in the design grid. So if you select e.g. the "background" property and you start clicking on different beans, the selection stays to "background" property in the Properties panel, as long the property exists for the clicked bean. - some bug fixes.. - I might be forgetting something.... We were thinking about implementing multiple selection of beans in the design grid.... but this appears to be a change that requires a lot of code to be changed and rewritten. So we left that idea (actually, for our needs it appears to be a rare case that we need to select several components together...). We try to consider the changes we make in the Abeille source code so that: - if the changes are related to the need to control Abeille from our application (e.g. the ability to hide menu commands), we try to make them so they appear to be useful for other people who would try to use Abeille from their own applications. And also to make them in such way so they don't affect Abeille when it is run as a standalone application. - if the changes are actually some enhancements, we try to make them to be useful for other Abeille users also (e.g. Reset To Default in Property Editor, remembering the last selected property and so on). We hope we succeed in that aspect so far... - if we fix issues that we think are bugs... well, we hope we managed to explore them really well and we didn't actually made other things worse with our fixes ;) But that can be verified by the code review some day. We have a lot more things related to Abeille in our project, e.g. custom property editors, custom components and so on, but these are all implemented as part of our project source. Whenever we have to, our classes extend Abeille's classes or implement Abeille's interfaces, so we fit the abstraction that Abeille expects. In that case you can update your local working copy against his most recent additions once finalized and then after code review on my end we can proceed to integrate your changes into the Abeille codebase.We didn't checkout the sources from the CVS, we actually downloaded this file: https://abeille.dev.java.net/files/documents/2703/57508/abeille_src_2_0.zip Then we placed the source in our own CVS repository. I had no choice but picking up the source that is marked as "stable". For the project that we develop I should ensure that this condition is met as much as possible - external libraries and programs that we use must be stable releases, no beta or milestones or whatever, unless really really necessary. And I wasn't sure how to checkout the "stable" branch/tag from the Abeille's module in the CVS repo. This is all mainly up to you... Still it is probably better if the the module structure does not become too complex and overloaded with branches/tags... We will need to get to this in fairly short order. When I inherited the project from Jeff there was only trunk from which to work from and coding changes have been managable and more linear in fashion. I hope that our intrusion into your project will not lead to too many difficulties for you :):):):):):) I do not insist about committing our changes in Abeille's CVS immediately. Probably I can just send you Abeille's changed source files so you can diff them against 2.0 release and see what we have changed. Or we can use another approach so you can make a review of our modifications, e.g. a patch file(s).... How do you think? The orthodox Easter holidays start here in Bulgaria followed by other national holidays and I will have a long 10 days vacation, till May 6th incl. Still, I usually check and respond to emails even when in vacation, but please excuse in advance any possible delays in my replies. And don't hesitate to ask about whatever you are interested in. Greetings, George
Plan your next roadtrip with MapQuest.com: America's #1 Mapping Site. |
|
|
Re: Abeille Forms Designer in use
by Todd Viegut
::
Rate this Message:
Hi George,
First off...I hope my email finds you doing well. I know it's been a bit since we last touched base. I've been swamped with a couple of projects, but things are finally slowing down a bit and I'm therefore trying to catch up on a few items for Abeille. We're in the midst of planning a transition to SVN as well as a couple of other items under discussion. Amongst the items on my list are plans for the eventual 3.0 release. That said I wanted to re-connect with you once again here and see if there's a way to minimally get a stable copy of the current rework you've done on Abeille? I'd like to start to run through it and then see and plan how it may be possible to work through code reviewing and then integration. That obviously can be a future event...but I thought I can at least get myself acquanted with what has been done...start a release 3.0 document...and lay out a plan. Anyway...I'm excited about doing this and hope it will be mutually beneficial. Warm Regards, ~Todd -----Original Message----- From: George Talev <geo@...> To: viegs@... Cc: dev@... Sent: Fri, 25 Apr 2008 12:51 pm Subject: Re: Abeille Forms Designer in use Hi Todd, thanks for your reply!
viegs@... wrote: Hi George,Thank you all for your work on the Abeille project! And that you keep it LGPL-ed!! We too :) I think in the short term we could work together on some collaberative code review.Why not.
Happy to hear that the product is being enhanced further. It is OK for me if our changes are applied after Math's. Most of our changes are in the direction of enabling Abeille to be run as a part of another program, not as a standalone program, so I hope that our and Math's work does not overlap :) To give you the basic idea, I will write some more info here about what we did with Abeille. There is an application that is part of the project we are working on, and this application needs the ability to allow users to create forms using our custom Swing components, together with editing and defining many other things, specific for the project. We also needed to have the form designer to be controlled by our application. We tried and liked Abeille as a standalone application and decided to try to make it integration-friendly, so it can be controlled programically from outside. Additionally, we implemented enhancements and fixes that we believe are suitable for the program, no matter if used as a standalone app or as part of another app. So we implemented things like: - "revert to default" - a pop-up-menu command in the Properties editor, which undoes to changes to the selected property by setting it the value taken from the same property of a newly constructed [for that purpose] bean object. - we added a new button in the Border editing window - "Custom border". This opens a new window where the user can type the FQN of a border class and there is the Abeille's Property editor in this window so the user can load and edit the props of the a border not listed in Abeille's default implementation. Well, the field for the border class name must be an editable combo that remembers recent entries.... but that will be added later :) - we added functionality that allows the main application (the one that uses Abeille internally) to hide menu items and menus. When the Abeille is opened as a part of another program, commands like "Close Project", "New Form", "Close Form", "Exit" etc might be unwanted. - there is a flag added, FormDesignerUtils.set/isIntegrated(). When set to 'true' by the main application, Abeille's code won't call "System.exit()' when its frame is closed. - we added functionality which allows the main application to feed Abeille with the XML of the forms and also to read back the XML of the edited forms. This way the main application takes the control of loading and saving the forms. - enhancement that allows the main application to add custom beans to the components palette in runtime. So we don't need to ask the user to add our special components to the palette by herself, neither we are forced to copy some Abeille configuration files to user's computer. - we made changes in the Java code generation routine and the XML serialization routine, because Abeille used to add unnecessary filler components to design gird cells, making it impossible to hide some component in the form in runtime and to let the layout manager to hide the whole row (in case that the row appears to be without other "visible" components).The explanation of this might be really unclear in this email, but anyway later we will give you very detailed information about what and why we've changed. - Java code generation routine didn't generate the code for the constraint Insets. This is now implemented. - added support for custom bean components which are containers (e.g. JPanel ancestors). Abeille needs such custom beans to be wrapped in a GridView. - Changed the visibility of some methods, added new methods that give the main application access to some Abeille internals, so they can be used from the main application. E.g. we needed to add new tab in the Properties editor panel. The idea is that we can't make this tab part of the original Abeille project, since it is very specific for our project and no one else will be interested in it. So we had to give our project access to some Abeille components and panels. - an interface is added (DescriptorSorter) which purpose is to be implemented by the main application, set by calling the appropriate Abeille (new) method and then the Properties editor calls sort() method of that object. That way the main application can set custom sorting for the properties. (e.g. we needed special sort order for the properties for some of our custom beans). - changed the way the Abeille looks for bean icons. If the bean class provides icons, Abeille will now use them in the palette. - visibility of JTable w/o rows - when the JTable has no rows, its height is 0. There was code in com.jeta.forms.gui.form.GridComponent.isShowing() that assumed that if the component's size is 0, then it is not showing. Well, for JTable components it is not correct - it breaks the painting of the table in runtime, namely - the table header does not repaint immediately when the user resizes the columns or reorders them. This happens only if in runtime the form is deserialized from Abeille's XML format. If you use generated Java-code for the form there is no problem, because GridComponent class does not take place then. (There is an issue in the project tracker about it, afair). - The Property editor now remembers the selected property when the user clicks on components in the design grid. So if you select e.g. the "background" property and you start clicking on different beans, the selection stays to "background" property in the Properties panel, as long the property exists for the clicked bean. - some bug fixes.. - I might be forgetting something.... We were thinking about implementing multiple selection of beans in the design grid.... but this appears to be a change that requires a lot of code to be changed and rewritten. So we left that idea (actually, for our needs it appears to be a rare case that we need to select several components together...). We try to consider the changes we make in the Abeille source code so that: - if the changes are related to the need to control Abeille from our application (e.g. the ability to hide menu commands), we try to make them so they appear to be useful for other people who would try to use Abeille from their own applications. And also to make them in such way so they don't affect Abeille when it is run as a standalone application. - if the changes are actually some enhancements, we try to make them to be useful for other Abeille users also (e.g. Reset To Default in Property Editor, remembering the last selected property and so on). We hope we succeed in that aspect so far... - if we fix issues that we think are bugs... well, we hope we managed to explore them really well and we didn't actually made other things worse with our fixes ;) But that can be verified by the code review some day. We have a lot more things related to Abeille in our project, e.g. custom property editors, custom components and so on, but these are all implemented as part of our project source. Whenever we have to, our classes extend Abeille's classes or implement Abeille's interfaces, so we fit the abstraction that Abeille expects. In that case you can update your local working copy against his most recent additions once finalized and then after code review on my end we can proceed to integrate your changes into the Abeille codebase.We didn't checkout the sources from the CVS, we actually downloaded this file: https://abeille.dev.java.net/files/documents/2703/57508/abeille_src_2_0.zip Then we placed the source in our own CVS repository. I had no choice but picking up the source that is marked as "stable". For the project that we develop I should ensure that this condition is met as much as possible - external libraries and programs that we use must be stable releases, no beta or milestones or whatever, unless really really necessary. And I wasn't sure how to checkout the "stable" branch/tag from the Abeille's module in the CVS repo. This is all mainly up to you... Still it is probably better if the the module structure does not become too complex and overloaded with branches/tags... We will need to get to this in fairly short order. When I inherited the project from Jeff there was only trunk from which to work from and coding changes have been managable and more linear in fashion. I hope that our intrusion into your project will not lead to too many difficulties for you :):):):):):) I do not insist about committing our changes in Abeille's CVS immediately. Probably I can just send you Abeille's changed source files so you can diff them against 2.0 release and see what we have changed. Or we can use another approach so you can make a review of our modifications, e.g. a patch file(s).... How do you think? The orthodox Easter holidays start here in Bulgaria followed by other national holidays and I will have a long 10 days vacation, till May 6th incl. Still, I usually check and respond to emails even when in vacation, but please excuse in advance any possible delays in my replies. And don't hesitate to ask about whatever you are interested in. Greetings, George
Stay informed, get connected and more with AOL on your phone. |
| Free Forum Powered by Nabble | Forum Help |