Antony Blakey <antony.bla...@gmail.com> wrote .. > I doubt this subthread is of any use to the OP at this point.
I run a software business, I generally look at product decisions in terms of cost/benefits from end to end over time not just looking solely at a specific item and specific time frame. > > On 31/05/2010, at 12:31 PM, lprefonta...@softaddicts.ca wrote: > > > Any suggestion is welcomed but I doubt we can find a core group of > > developers that will "win" this survey. > > It's a survey group of 1 i.e. what are *his* responses to those questions. Two alternatives seem to gather some support, Swing and SWT. Now what are the cost/benefits of choosing SWT ? > > > Yep but then you need to ship the DLLs (and any other native implementations > for > > the various platforms) with a synced version of the wrapper. > > Of course the native libraries may vary according to the platorm/maintenance > > releases, ... > > And yet, somehow, commercial software is produced ... Maybe but does it have to be more painful and complex than necessary ? What value brings SWT ? a) Performance ? Maybe a few years ago but presently Swing and SWT are similar in terms of performance in general. b) Swing is bundled in the JRE, SWT is not. This means some extra work somehow. c) Cosmetic aspect ? SWT "wins" for its ability to look like other apps on a given platform. Swing offers a uniform look and feel. So the only "feature" offered by SWT if I follow your point is c). At what cost ? > > > So should we expect problems in other OSes ? What about testing then ? > > Do we multiply the number of test suites to run by the number of platforms > > we support multiplied by the different versions of SWT ? > > No, you treat SWT as a black box as regards testing. It has it's own test > regime > and cross-platform validation. Impacts on testing/deployment: a) Black boxes are good until top layers get hit. You still need to manage dependencies between the top wrapper and the bottom layers. Swing has a major advantage here. No native wrappers, no need for a complex installation process or per platform dependency management. b) No test completed = not a product yet. You have to test before delivering anything to a desktop and that includes all the variants you intend to support. Swing is the same everywhere so the occurrences of GUI related problems are reduced. SWT opens the gate to potential problems since it is implemented in different components depending on the platform. Swing wins here. c) Building/packaging/maintaning variants for every desktop type supported is significant work. Swing wins here. d) I do not see writing installers has being a mundane and funny task. Having to write per desktop variant installers is another drawback of SWT. Delivering a single jar on all platforms is a big bonus. Complex installers have to be tested themselves, there subject to the same problems as any piece of software whatever good the tool you use maybe. Another level of complexity.... Swing wins here. Back to "why does producing software has to be more painful than necessary" and "what value brings SWT overall". > > > Were not in the cosmetics business however so we speak for our business > > (cross-platform, cross-language, cross-....) > > You are begging the question then. Swing has prove itself up to know (and improved a lot), why get entangled in a complex process with all the above ramifications ? Simplicity as some value. You should meditate a bit on this. Luc P. > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > The trouble with the world is that the stupid are cocksure and the intelligent > are full of doubt. > -- Bertrand Russell > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first > post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
