visualswing-developers Mailing List for Visual Swing
Status: Pre-Alpha
Brought to you by:
gladiator
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(22) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Timo H. <tim...@ko...> - 2003-07-03 20:09:44
|
> How 'bout we keep the Features list open for another week, and then put > it into a somewhat final form. In other words, if there's something you > want included or excluded, now is the time to put your two cents in! > The features list looks great. Here are some comments/questions: One issue that is not totally clear for me: the (internal) format in which we are going to save "works in progress". If we can save the works in .java format it is fine, but for me it seems that coding of this kind of feature (saving, loading and parsing of java files) is very big and difficult work. What do you think about the following: There is an "internal" model which stores all the data related to components, containers, locations of components etc (I thing this is needed regardless of implementation principle). The model will be updated "automatically" when user edits the "GUI" graphically. The model (which in practice is "work in progress") can be saved and loaded e.g. in XML format or in any other format (.java file). If it seems reasonable, it can be done so that it is easy to add/remove new classes that implement the saving/loading of certain format. I am not sure is this really needed but in this way it might be possible to add new formats if needed. I thing the XML (or similar) format is what should be implemented first but we can still implement a new class that stores the model in .java format. For me the format doesn't matter, both are ok but XML (or similar) seems more easy to implement at the first phase. -- Another question about the views: Is it so that there will be "editing" view and "runtime" view. I didn't see this in the features list but I assume those are needed? Timo |
From: Scott C. <sc...@mi...> - 2003-07-02 21:16:47
|
Todd said - > Also, we still need someone to step up and put together the coding > convention we're going to use, or at least put together a proposal. I think every group of programmers has a slightly different take on the convention issue. Some follow Java's standard more religiously than others; so coming to agreement on this might be difficult. Rather than writing our own though, it might be nice to at least follow in the footsteps of those that have gone before us (open-source wise of course). Of the ones that I've read I like the JBoss convention's the best and they are available at http://jboss.org/index.html?module=html&op=userdisplay&id=developers/gui des/codestyle. Scott Corley |
From: todd <tod...@ya...> - 2003-07-02 14:14:51
|
How 'bout we keep the Features list open for another week, and then put it into a somewhat final form. In other words, if there's something you want included or excluded, now is the time to put your two cents in! Also, we still need someone to step up and put together the coding convention we're going to use, or at least put together a proposal. Todd |
From: <sc...@mi...> - 2003-06-27 15:25:03
|
> As far as the internal format/xml, let me run this by > you (I'm going to get into design a bit here so > forgive me for jumping the gun): The current design > of VS uses actual Swing components. I had suggested > at one time that we use an interface (call it > VSComponent) which wraps a JComponent, methods for > generating the .java code, an icon to be used on the > toolbar and some other things which I don't remember > right now. I figured we could use an XML file to tell > VS where to find the classes that implement > VSComponent, and have these loaded at runtime. If we > add new components, we can ship them as standalone > classes and amend the xml config file. > Is this kind of what you had in mind with the internal > format? That is kind of what I was thinking although I'd rather not have the user-generated components editing our configuration files. I was thinking that the components offered on the toolbar would have definition files - possibly in xml - in a config directory and when the user created a component that he/she wanted to add to the toolbar, he/she would save his/her component in the xml format to a specific directory and then on the next start-up that component would be offered on the toolbar in a "user section". > I had suggested at one time that we use an interface > (call it VSComponent) which wraps a JComponent, methods for > generating the .java code, an icon to be used on the > toolbar and some other things which I don't remember > right now. I like the idea of wrapping the components rather than using them directly and they could certainly hold information regarding the icon for the toolbar and similar uses important to the interacting with the properties/event listeners for the component. I think I'd rather have a seperate classes that have the responsibility of knowing how to generate .java code or any other format. Any thoughts about that? Scott Corley |
From: todd r. <tod...@ya...> - 2003-06-27 14:34:53
|
Let's wait to see what other feedback we get, but I think we're on the right track. This will definately help move us in the right direction! As far as the internal format/xml, let me run this by you (I'm going to get into design a bit here so forgive me for jumping the gun): The current design of VS uses actual Swing components. I had suggested at one time that we use an interface (call it VSComponent) which wraps a JComponent, methods for generating the .java code, an icon to be used on the toolbar and some other things which I don't remember right now. I figured we could use an XML file to tell VS where to find the classes that implement VSComponent, and have these loaded at runtime. If we add new components, we can ship them as standalone classes and amend the xml config file. Is this kind of what you had in mind with the internal format? --- sc...@mi... wrote: > Todd wrote : > > Are you talking about custom, user created classes > > that inherit from JComponent? If I'm wrong, could > you > > elaborate? > > Right, I was thinking a developer develops a JPanel > that he/she uses for a number of GUI applications it > would be nice if he/she could add that panel > subclass to a new GUI rather than having to recreate > it each time. > > > Is this the [internal] format that we're going to > save "works > in progress"? > > I would hope that we could save "works in progress" > in a valid state in a .java format (or any format > for that matter); whether it is fully functioning is > up to the user. I was thinking that the internal > format would be more used to add user-created > elements to our set of usable components. (Maybe > this is unneccesary.) > > > This one may get sticky. Maybe I should make sure > I > > understand the intent - I can take any .java class > > (presumably that inherits from JComponent) and > have VS > > load it up? > > > > I think it would be awesome if we could reliably > parse > > .java files, but I also think it's going to be a > > beast. > > I was thinking the same thing; whatever restrictions > we made to the output of our generated classes would > have to be applied to these classes. But it would > be nice if the user could start a GUI in Forte, > realize how limiting that environment is and switch > over to VisualSwing without starting from scratch. > > > > > The more I think about this one, the more I think > that > > maybe we don't provide an editior (you drag and > drop > > components, set properties and provide code for > > events, but not manipulate the .java file) in the > > standalone version. Instead, we have a simple to > use > > GUI Builder that outputs the file formats > discussed. > > Then we provide a version that is a plug-in, and > we > > leverage that tools editor. That way, beginners > can > > get started without worrying about setting up a > full > > IDE - once they're ready (and hooked on Java), > they > > advance to the next level. > > I tend to agree I think we have our work cut out for > us with the features listed above. If our design is > good enough, I would hope that at the point we think > about operating as a plugin to another IDE we could > provide bi-directional hooks to allow interaction > between the GUI view and whatever text editor is > available. > > > When you say "first release", I assume you're > talking > > about version 1.0, and not the first "file > release" > > that we post on the sourceforge download page. If > I > > understand that correctly, I concur 100%. > > Yes, 1.0. > > Do you think these clarifications warrant a revision > or should we wait for further feedback? > > Scott Corley > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An > INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% > Monthly Commission! > INetU Dedicated Managed Hosting > http://www.inetu.net/partner/index.php > _______________________________________________ > Visualswing-developers mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualswing-developers ===== The only "dumb question" is the one you were too afraid to ask. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: <sc...@mi...> - 2003-06-27 13:38:09
|
Todd wrote : > Are you talking about custom, user created classes > that inherit from JComponent? If I'm wrong, could you > elaborate? Right, I was thinking a developer develops a JPanel that he/she uses for a number of GUI applications it would be nice if he/she could add that panel subclass to a new GUI rather than having to recreate it each time. > Is this the [internal] format that we're going to save "works > in progress"? I would hope that we could save "works in progress" in a valid state in a .java format (or any format for that matter); whether it is fully functioning is up to the user. I was thinking that the internal format would be more used to add user-created elements to our set of usable components. (Maybe this is unneccesary.) > This one may get sticky. Maybe I should make sure I > understand the intent - I can take any .java class > (presumably that inherits from JComponent) and have VS > load it up? > > I think it would be awesome if we could reliably parse > .java files, but I also think it's going to be a > beast. I was thinking the same thing; whatever restrictions we made to the output of our generated classes would have to be applied to these classes. But it would be nice if the user could start a GUI in Forte, realize how limiting that environment is and switch over to VisualSwing without starting from scratch. > The more I think about this one, the more I think that > maybe we don't provide an editior (you drag and drop > components, set properties and provide code for > events, but not manipulate the .java file) in the > standalone version. Instead, we have a simple to use > GUI Builder that outputs the file formats discussed. > Then we provide a version that is a plug-in, and we > leverage that tools editor. That way, beginners can > get started without worrying about setting up a full > IDE - once they're ready (and hooked on Java), they > advance to the next level. I tend to agree I think we have our work cut out for us with the features listed above. If our design is good enough, I would hope that at the point we think about operating as a plugin to another IDE we could provide bi-directional hooks to allow interaction between the GUI view and whatever text editor is available. > When you say "first release", I assume you're talking > about version 1.0, and not the first "file release" > that we post on the sourceforge download page. If I > understand that correctly, I concur 100%. Yes, 1.0. Do you think these clarifications warrant a revision or should we wait for further feedback? Scott Corley |
From: todd r. <tod...@ya...> - 2003-06-26 23:43:42
|
Scott, you rock! Thanks for doing this, it looks great. I have a few thoughts, embedded below: --- Scott Corley <sc...@mi...> wrote: > On 20-06-2003, a brief features list was distributed > to the developer's > mailing list. Although not much in the way of > response has been made, I > thought we could flesh out more details regarding > that list and > hopefully post the new features list on the website. > > GUI view - > A> Will allow a user to develop Graphical User > Interfaces with Java's > Swing library. > B> Will support the Layout Managers provided for > in the Swing and AWT > libraries. > C> Will support GUIs created using no Layout > Manager and absolutely > positioned/sized components. > D> Will provide the usage of all Swing containers > and other > components to build a GUI. > E> Will also allow the user to create template > components that may be > added to a GUI like any other standard Swing > components. Are you talking about custom, user created classes that inherit from JComponent? If I'm wrong, could you elaborate? > F> Will allow the user to set all component > properties and add Event > Listeners to components. > > File formats - > A> Will generate .java files for the GUI created. > B> Will generate .class files for the GUI > created. > C> Will generate some other internal format (most > likely XML) which > will allow the components created to be added to the > set of usable > components. Is this the format that we're going to save "works in progress"? > D> Will read .java files for existing GUI > (whether created by the > tool or not). This one may get sticky. Maybe I should make sure I understand the intent - I can take any .java class (presumably that inherits from JComponent) and have VS load it up? I think it would be awesome if we could reliably parse .java files, but I also think it's going to be a beast. > E> Will read existing files in our internal > format. > > Code view - > A> Should incorporate a text editor to allow the > user to edit Java > code manually to manipulate the GUI as well as > through the GUI view. > (Whether we are going to author our own text editor > or act as a plug-in > to a project with an existing text editor is > undecided.) The more I think about this one, the more I think that maybe we don't provide an editior (you drag and drop components, set properties and provide code for events, but not manipulate the .java file) in the standalone version. Instead, we have a simple to use GUI Builder that outputs the file formats discussed. Then we provide a version that is a plug-in, and we leverage that tools editor. That way, beginners can get started without worrying about setting up a full IDE - once they're ready (and hooked on Java), they advance to the next level. > > Please review and comment on the points listed > above. > > Personally, I would like to see the first release > attempt to fulfill all > of the GUI View and File Format items. When you say "first release", I assume you're talking about version 1.0, and not the first "file release" that we post on the sourceforge download page. If I understand that correctly, I concur 100%. > > Scott Corley > ===== The only "dumb question" is the one you were too afraid to ask. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Scott C. <sc...@mi...> - 2003-06-26 23:04:28
|
On 20-06-2003, a brief features list was distributed to the developer's mailing list. Although not much in the way of response has been made, I thought we could flesh out more details regarding that list and hopefully post the new features list on the website. GUI view - A> Will allow a user to develop Graphical User Interfaces with Java's Swing library. B> Will support the Layout Managers provided for in the Swing and AWT libraries. C> Will support GUIs created using no Layout Manager and absolutely positioned/sized components. D> Will provide the usage of all Swing containers and other components to build a GUI. E> Will also allow the user to create template components that may be added to a GUI like any other standard Swing components. F> Will allow the user to set all component properties and add Event Listeners to components. File formats - A> Will generate .java files for the GUI created. B> Will generate .class files for the GUI created. C> Will generate some other internal format (most likely XML) which will allow the components created to be added to the set of usable components. D> Will read .java files for existing GUI (whether created by the tool or not). E> Will read existing files in our internal format. Code view - A> Should incorporate a text editor to allow the user to edit Java code manually to manipulate the GUI as well as through the GUI view. (Whether we are going to author our own text editor or act as a plug-in to a project with an existing text editor is undecided.) Please review and comment on the points listed above. Personally, I would like to see the first release attempt to fulfill all of the GUI View and File Format items. Scott Corley |
From: Timo H. <tim...@ko...> - 2003-06-26 17:13:25
|
Scott wrote: > > > > Other than IDE plugin, what other sort of > > application would you imagine > > VisualSwing be embedded into? > > I have another (not so active) project in SF: http://sourceforge.net/projects/pronetha It is like integrated IDE and platform to run application programs over the network. Client part is coded by Java and server side by C++. I have planned to add there possibility to build GUIs graphically for the application programs (and have done already some prototypes) but designing and coding of this kind of functionality is not piece of cake. > > If an Eclipse plugin or standalone IDE won't work for > you Timo, try to keep reminding the team to keep > things modular. That way, you should be able to pull > out major portions to integrate into your other > project. > Yes, I think you are right. It may be possible that my project needs some features which are not necessary or even reasonable to add to visual swing. But if it is needed and ok to others, I can do both develop visual swing and maintain modified version that is integrated to my own project. What do you think is this ok for you? - Timo P.S. Yes, I am going to change the look of my projects's home page. It probably looks very messy in some browsers and has too much necessary items :-) |
From: todd r. <tod...@ya...> - 2003-06-26 04:20:05
|
--- Scott Corley <sc...@mi...> wrote: > > Timo said - > > > > I was wondering might it be possible to use visual > swing like > > "plugin" in another software. So, there should not > be necessary need > to > > build another GUI builder. > > > To be honest, for my personally it would be nice > if visual swing can > be > > implemented as "Java Bean" or so that it can be > added e.g. to JPanel > (I > > mean that visual swing is e.g. derived from > JComponent and can be > added > e.g. to the JPanel). It should be also > possible to "start" > visual swing > > from the main-method like any other normal > stand-alone java > application as > planned earlier. > > Other than IDE plugin, what other sort of > application would you imagine > VisualSwing be embedded into? > > I think the possibility of making visual swing into > an IDE plugin is not > a bad idea (and has been mentioned by several others > in earlier > postings); it would keep us from having to author a > text editor for > example, if we were a plugin to something that > already contained a text > editor. But that means that we must tie ourselves > to the development of > that other product. If we do decide to become a > plugin, I think we > should stick to Eclipse, JEdit, etc. - namely > something open source with > a fairly stable API. Personally, I'd like to see a standalone IDE, at least initially. As I've mentioned before though, I love Eclipse and fully support building VS as a plugin. I agree that limiting the scope would be wise as trying to make this work for every editor out there will be impossible. If an Eclipse plugin or standalone IDE won't work for you Timo, try to keep reminding the team to keep things modular. That way, you should be able to pull out major portions to integrate into your other project. > > Timo said [regarding layouts...] > > > But, probably this is too far compared to the > original ideas. > > Do the original designers of this project have an > opinion on supporting > layout managers in the project? To be honest, I don't think it matters. If anyone feels strongly one way or the other, let them make a case for it. Many of us joined this project because we wanted to create a free, open source java IDE, but knew we couldn't make it by ourselves. With that in mind, whatever the group as a whole decides, is what will be supported. > Because I agree > with Timo, I think > including layouts is critical to any GUI design tool > for Java. I also > think that most developers familiar with Swing would > find the project > lacking if it didn't support them (even if it wasn't > the default > behavior). Seems to me the group has spoken - support for layout managers is in. > > Now that we have a list of possible features, can we > come to any > agreement on what should go in a first release for > the project - so that > some more thought might be put into design? Scott, are you willing to write something up? Maybe something we can post? > > Scott Corley > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An > INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% > Monthly Commission! > INetU Dedicated Managed Hosting > http://www.inetu.net/partner/index.php > _______________________________________________ > Visualswing-developers mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualswing-developers ===== The only "dumb question" is the one you were too afraid to ask. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Scott C. <sc...@mi...> - 2003-06-26 01:01:39
|
Timo said - > I was wondering might it be possible to use visual swing like > "plugin" in another software. So, there should not be necessary need to > build another GUI builder. > To be honest, for my personally it would be nice if visual swing can be > implemented as "Java Bean" or so that it can be added e.g. to JPanel (I > mean that visual swing is e.g. derived from JComponent and can be added > e.g. to the JPanel). It should be also possible to "start" visual swing > from the main-method like any other normal stand-alone java application as > planned earlier. Other than IDE plugin, what other sort of application would you imagine VisualSwing be embedded into? I think the possibility of making visual swing into an IDE plugin is not a bad idea (and has been mentioned by several others in earlier postings); it would keep us from having to author a text editor for example, if we were a plugin to something that already contained a text editor. But that means that we must tie ourselves to the development of that other product. If we do decide to become a plugin, I think we should stick to Eclipse, JEdit, etc. - namely something open source with a fairly stable API. Timo said [regarding layouts...] > But, probably this is too far compared to the original ideas. Do the original designers of this project have an opinion on supporting layout managers in the project? Because I agree with Timo, I think including layouts is critical to any GUI design tool for Java. I also think that most developers familiar with Swing would find the project lacking if it didn't support them (even if it wasn't the default behavior). Now that we have a list of possible features, can we come to any agreement on what should go in a first release for the project - so that some more thought might be put into design? Scott Corley |
From: Timo H. <tim...@ko...> - 2003-06-25 19:45:30
|
Hi all, I joined a few weeks ago to this project. I am from Windows environment and not so familiar to open source development (escpecially not familiar in co-operation that is needed in open source development) but want to learn. I have another project to which I was planning to develop same kind of GUI development tools. However, I joined this project because wanted to help with visual swing project and learn more how to build GUI editors. There was also idea that perhaps we can share some code between projects. However, when thinking more, I was wondering might it be possible to use visual swing like "plugin" in another software. So, there should not be necessary need to build another GUI builder. To be honest, for my personally it would be nice if visual swing can be implemented as "Java Bean" or so that it can be added e.g. to JPanel (I mean that visual swing is e.g. derived from JComponent and can be added e.g. to the JPanel). It should be also possible to "start" visual swing from the main-method like any other normal stand-alone java application as planned earlier. What do you thing about this kind of idea? It would be great if visual swing can be integrated to another softwares, but if this idea is not ok for others, it is great for me to help with visual swing project and learn more with it. I have also some comments to Scott's mail: Although I was wondering if we might also consider possibly an XML definition of elements (ala XUL) so that a user might develop (for example) custom panels that could be added to the palette of choices. (This also assumes that can store user creations in an XML format that we can read in. + 1 for "Persistent data saved as xml") This sounds good. I think it would be nice to add also possibility to add "any" elements to the palette of choices. So that user can develop any kind of complex componets (including nested panels/components) e.g. also using another development tools and add those to the palette of choices. I'd like to know if a use case for the project is to allow the user to create something as complex as the UI that we develop for this project? If so, I think layouts are a requirement. My opinion is that layouts are required and it should be possible to develop a quite complex UIs with visual swing. The only problem that I have with that is that absolutely positioned and absolutely sized elements in Swing tend to not resize well when the user changes his/her window size. (Please note: I'm coming from a Swing-centric UI background.) I agree. I was wondering is it possible to use e.g. new SpringLayout but I haven't found much examples about this layout from the web. Some times ago I was thinking might it be possible to predefine (=draw by development tool=>by visualswing) "forms" which are like panels with own layout and predefined places for components. User might then be able to drag and drop components from the palette to the predefined places on the form and components will be automatically resized on the correct places. User should be possible to create new forms and define rules between "places" of components so that when resized, the forms and components in it are resized based on those rules. (like in SpringLayout). But, probably this is too far compared to the original ideas. Thanks, Timo |
From: Inung H. <in...@vi...> - 2003-06-22 12:33:50
|
Hi All: My name is Inung and I am new in the project also in Java development. I have WinCVS installed and am able to check out the source. If there is anything about the CVS. I might be able to help. About the project, I would like to start some small code task to learn the project. I am interested in maintain the web site. If you need any help. Thanks! Inung Huang |
From: Scott C. <sc...@mi...> - 2003-06-21 13:34:41
|
> Features: > Gui view > Code view > Generate .java code > Generate .class files > Persistent data saved as xml > Ability to set properites > Abstracts adding event listeners I remember Senthil describing using introspection on the GUI components that we allow the user to use. Although I was wondering if we might also consider possibly an XML definition of elements (ala XUL) so that a user might develop (for example) custom panels that could be added to the palette of choices. (This also assumes that can store user creations in an XML format that we can read in. + 1 for "Persistent data saved as xml") > Options to be considered later: > User selected layout type I'd like to know if a use case for the project is to allow the user to create something as complex as the UI that we develop for this project? If so, I think layouts are a requirement. > The basic appearance should be a mix of Visual Studio and Forte. For us non Visual Studio, types does anyone have screen shots of it to help with a feel for that product? Is that where the click-and-drag placement of elements comes from? The only problem that I have with that is that absolutely positioned and absolutely sized elements in Swing tend to not resize well when the user changes his/her window size. (Please note: I'm coming from a Swing-centric UI background.) |
From: todd <tod...@ya...> - 2003-06-20 18:37:18
|
Since one of the first things we need is a features list, here's a very basic list to get us started. This is from comments to the mailing list, emails I've recieved and just guesswork. Any feedback is greatly appreciated (or maybe that should be "sorely needed"). Features: Gui view Code view Generate .java code Geneate .class files Persistant data saved as xml Ability to set properites Abstracts adding event listeners Options to be considered later: Swing, awt, swt support User selected layout type The basic appearance should be a mix of Visual Studio and Forte. |
From: todd r. <tod...@ya...> - 2003-06-16 14:22:48
|
The closest thing I've seen to a description is what's on the Summary and Home pages for the project. I think it's both good and bad - we don't have a lot of direction, but we also don't have any restrictions. For me, the description that I am most interested in is the one which compares Visual Swing to Visual Studio (probably version 5/6). I think it's a well known environment and would be fairly easy to use as a model. The other environment that I'd like to incorporate is the Mozilla Composer tab-like, multi-view concept. This isn't too far a leap from the Visual Studio idea, except that the code and gui are better separated in Composer. Scott, would you be interested in compiling the feature list as we hash it out on the mailing list? --- Scott Corley <sc...@mi...> wrote: > First welcome to all new members from a newbie. > > I agree with Todd that things he listed in his mail > are crucial things > to be done but I think the Feature List MUST be > started first (except > maybe the coding conventions discussion). Without a > list of at least > temporary goals, I think it makes it rather > impossible to get motivated > to do any of that other work. Is there a more > thorough description of > the intent of the tool from the original developers > that we might start > with or are we just supposed to hash out the ideas > via the mailing list. > > As far as coding conventions, I like the Java > standards but we don't use > them where I work ( whole bunch of old C programmers > run our department > - no offense to anyone who is a C programmer they > just don't consider > using Java standard coding conventions that > important is all I meant :-) > ) . We actually use something more similar to > JBosses coding style - so > whichever everyone agrees to I'm all for it. > > Scott Corley > ===== The only "dumb question" is the one you were too afraid to ask. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Scott C. <sc...@mi...> - 2003-06-14 13:50:51
|
First welcome to all new members from a newbie. I agree with Todd that things he listed in his mail are crucial things to be done but I think the Feature List MUST be started first (except maybe the coding conventions discussion). Without a list of at least temporary goals, I think it makes it rather impossible to get motivated to do any of that other work. Is there a more thorough description of the intent of the tool from the original developers that we might start with or are we just supposed to hash out the ideas via the mailing list. As far as coding conventions, I like the Java standards but we don't use them where I work ( whole bunch of old C programmers run our department - no offense to anyone who is a C programmer they just don't consider using Java standard coding conventions that important is all I meant :-) ) . We actually use something more similar to JBosses coding style - so whichever everyone agrees to I'm all for it. Scott Corley |
From: todd <tod...@ya...> - 2003-06-13 15:47:40
|
I know some of the developers have been waiting around wondering what they're supposed to be doing. I've put together a list of stuff that I think we need - if you have any other thoughts, please post them!!! Here are some things we should get done soon: Coding style and convention - someone needs to come up with some rules on how source code should be laid out, what kinds of naming conventions we should use, etc. For an example of a code style guide, you can look at JBosses example: http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/guides/codestyle Build script - I prefer Ant, but we could open this up to discussion. We need someone to lead this though - keep the build script up to date, address issues that developers are having, etc. As with all the tasks I'm listing, taking on the Build Scripts would not mean that you'll get so buried in Ant tasks that you don't get to write other code. Feature list - It would help if someone could compile a list of things the final product should contain. Also, status of the implementation of each feature needs to be tracked. This list will help us determine coding tasks. CVS - Jonathan and/or I will have to init cvs for this project. After that, we'll open it up for everyone else to commit changes. Since I've never used cvs before, if there's someone who is comfortable with it and wants to help manage the cvs tasks, please let me know. Documentation - Anyone want to be in charge of documentation? A lot of documentation will come from javadoc comments, but a User Manual, install instructions, etc would help. Whoever takes this on shouldn't be overburdened. I envision this person would contact other developers and ask them to write a few paragraphs about a new feature they added. They would still get to write as much code as they wanted. Web Master - This person would keep the Home Page up to date (not up to the minute or anything, but making sure it doesn't talk about version 0.0.1 if we're working on the final version). Since sourceforge gives us shtml, php and access to a mysql database, if someone wants a way to show off their skills in data/web apps, this might be a good task to take on. Again, these are some initial ideas. If someone says they want to take on one of these, it doesn't mean it's theirs for life. Do as much or as little as you want. If take on something and you need help, just let the group know - I'm sure we'll be able to find someone willing to help. If you're interested, or if you have questions, post a message to the list. If you think of other things that need to be done, post that too. Todd |
From: todd <tod...@ya...> - 2003-06-13 14:54:07
|
Welcome to the following new Visual Swing developers: Garry Singh Inung Huang Ramprakash Govindarajan Sachin Dhir Timo Harju Wenceslao Arenas Robles We should have more than enough brains and talent to get Visual Swing rolling again. Now that the development team is established, we need to map out the future of Visual Swing. As previously mentioned, feel free to post ideas or questions to this mailing list. For those who are new to sourceforge and/or mailing lists, you can send messages to this list by sending an email to: vis...@li... Once again, a big "Welcome" to our new developers! |
From: todd <tod...@ya...> - 2003-06-10 19:41:01
|
We're getting the development team assembled. There will be at least 4 more developers added later this week or early next. After that, we should have plenty of talent to move this project forward. Next week, I'll be posting some ad hoc tasks that people can take and run with. This isn't anything official, just thoughts on what we'll need to get done. If you have an idea of something that needs to be done, either post it to the mailing list, or email me directly. Between now and then, please feel free to post ideas or questions about what Visual Swing should include. From time to time, I may mention the "final product". While Open Source projects are never "final", and they aren't really "products", this is my way of talking about what we want the program to be when it's completed. We'll try to accomodate everyone's wishes, but if we hit a conflict and we must decide to go either left or right, Jonathan gets to be the deciding vote (it is his project after all). This mailing list should be a dumping ground for you all to share ideas, argue about design issues and congratulate each other on achievements. If you have questions about getting work done, even if it's not related to Visual Swing, go ahead and ask your fellow developers if anyone has skills to help you. The mailing list is our "office" and I hope we can have a really informal workplace. Till next time! Todd |
From: Senthil K. <sen...@re...> - 2003-06-07 16:58:55
|
Hi, These are my ideas of how Visual Swing should look like. 1. Include all GUI components in Swing and allow editing of properties. The property editor should look like Forte's, allowing both editing of String values (like a button's label) AND Object values like say the Dimension or Font of the object.. I personally used reflection to list the properties of the added component and list them in the table (list all methods that are like getXXX()) and when an entry is changed, use setXXX() again using reflection, to update the component. 2. Allow setting of layouts visually 3. A integrated editor, that lists all events associated with a component like that in Visual Basic. 4. Save the layout to an XML file or some persistent form and open it again, apart from generating Java code. I hope I'm not taking it too far. Regards Senthil ___________________________________________________ Impress your clients! Send mail from me @ mycompany.com . Just Rs.1499/year. Click http://www.rediffmailpro.com to know more. |
From: Senthil K. <sen...@re...> - 2003-06-07 13:44:36
|
Hi, I'm Senthil, the latest addition to visual swing. I went through the source code of Visual Swing, so I have a good idea what it's all about. Now what's the next step that we have to take? I'd like to know which part we might start developing. Regards Senthil ___________________________________________________ Impress your clients! Send mail from me @ mycompany.com . Just Rs.1499/year. Click http://www.rediffmailpro.com to know more. |
From: todd <tod...@ya...> - 2003-06-05 15:20:36
|
Welcome Scott Corley to the Visual Swing development team. Scott has more than 3 years Java experience and has taught beginners to the Java language to use the Swing library. Scott has some great ideas and should be a another great addition to our team. Welcome to Visual Swing Scott! Todd |
From: todd <tod...@ya...> - 2003-06-04 16:15:54
|
Visual Swing has added another new developer to our ranks. Senthil is also a member of other projects on Sourceforge (take a look at some of them if you get a chance) and has done quite a few applications using Swing. Senthil even began building something similar to Visual Swing, but realized that it was too big for one person to do alone. Welcome to Visual Swing Senthil! Todd |
From: todd <tod...@ya...> - 2003-06-03 22:37:52
|
Visual Swing has a new developer on the team - Gopichand. With 4 years of Java experience, this is Gopichand's first Open Source project. Welcome to Visual Swing, Gopichand! Todd |