I have what I hope is a reasonable question: Why SWT with JFace? Is there some reason that combination works well? The reason I'm asking is because I am starting to work on building a web version of what I created in Swing, and I'm not sure of the best approach. I want to skip past Applets and have something running server side if possible.
Amy Matthias Basler wrote: > Andrea Aime wrote: > > >>> 1. Building widgets for Swing AND SWT at the same time did turn out >>> to be much more work than I expected. Almost no chance of sharing any >>> code... >>> >> And it makes sense to build one for Swing and not for SWT in my opinion. >> Why? Because if you're targeting SWT you'll probably want to use >> uDig plugins to build your software anyways... the level of reuse would >> be higher. It's hard to find fure SWT/JFace apps around, most are really >> using the RCP (Azureus is one of the most notable exceptions). >> > > I do see a need to build SWT/JFace widgets as well - for two reasons: > > 1. uDig is missing some widgets, most notably a widget for simplyfing the > creation of more complex SLD styles and for more convenient CRS > selection/assembly (I have created the latter one.) > > 2. Although most people interested in SWT/JFace would probably start > extending uDig, this is not always true. Some might just want to use a few of > it's widgets and create a different kind of GIS app from them, because uDig > does not fit their needs or because they already have an application that > just misses spatial support. For example, as the uDig team has itself noted, > uDig doesn't have a "GIS viewer" and is overdesigned if you just need a view > to show some spatial data in you own app. This is something that could imho > addressed if there were a separate map display widget equivalent to the > JMapPane. > > > >>> - Should it support >>> only Geotools or should it support other GIS libraries via an >>> additional layer of abstraction? >>> >> No... too much rope, you end up hanging yourself. >> > > Exactly my experience... ;-) > > >> I'd say, take GO-1 as an inspiration, but a spec like GO-1 does not >> make much sense in my opinion... what do you interoperate with? Nothing. >> So there's no point in having a standard, whilst it's useful to have >> a reference design to help you develop your own way of solving the >> problem. >> > > Agree. > > >>> 5. Different goals. I am geared towars a desktop GIS and image >>> processing, GeoTools/uDig still has its priority in WebGIS (OGC) and >>> vector data. >>> >> OGC yes, vector data... hum... have a look at what the 2.3.x branch >> and Simone and Alessio work can do and be amazed :-) >> > > Yes, this is on my list of things to try out. > > >> Hmm... just to add to your rant, I'd say that we need an uDig >> competitor, even a small one, to fuel the development of anything swing >> related (by small, I mean something that does not aim to be a platform, >> but just an app). Developer of the Swing components should eat their own >> dog food by using it in a real app, otherwise it becomes just an >> "academic" effort. >> > > I fully agree. > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
