[nfbcs] An Analysis of JAVASWT Classes

John J. Boyer john.boyer at abilitiessoft.com
Thu Jan 19 04:34:56 UTC 2012 

Steve,

Well, I've been programming in Java for  only about a year and a half. I 
started out with SWT at the beginning. So I didn't have anything to 
unlearn. When we start handling tactile and visual images in 
BrailleBlaster I will be using the SWT graphics classes.

I'm not sure that Dick's note said that classes that have nothing to do 
with the UI couldn;t be used with SWT. I would like to see some 
examples. Maybe  i'll write to him about this.

John

On Wed, Jan 18, 2012 at 03:21:26PM -0600, Steve Jacobson wrote:
> John,
> 
> The eye-opener here for me is that I always thought that a JAVA program could be written however one 
> wants to write it but just make sure to use SWT for the user interface.  What his note said that was new 
> to me is that if you use SWT, it affects ones ability to use other JAVA classes to do things that are 
> not related to UI.  For example, he would like to use other JAVA classes to handle the creation and 
> display of the drawings that are made, but he can't without doing a lot of modification to class 
> libraries that isn't always even possible.  If one is writing a braille translator, one knows from the 
> outset that that it has to be accessible.  However, if one has a large application made of processes 
> already using JAVA classes, changing UI components to SWT could impact other processes that one would 
> not normally need to change for accessibility.  In some cases, therefore, the effort to make an 
> application accessible if far greater than it appears from the outside.
> 
> I believe that John is right that our most effective approach so far has been to magnify the effect of 
> our small market by getting laws and regulations in place that reuire accessibility in certain cases.  
> However, in terms of expectations, and perhaps even where we apply pressure, we need to understand where 
> the difficulties lie in making something accessible.  
> 
> Best regards,
> 
> Steve Jacobson
> 
> On Wed, 18 Jan 2012 15:02:48 -0600, John J. Boyer wrote:
> 
> >Right. I am simply avoiding anything that uses swing or the awt classes, 
> >since they are inherently inaccessible. However, there is no real 
> >alternative to SWT if you want to develop a cross-platform Java 
> >aplication. 
> 
> >I'm a pragmatist. 
> 
> >John
> 
> >On Wed, Jan 18, 2012 at 01:50:56PM -0600, Steve Jacobson wrote:
> >> John,
> >> 
> >> I don't think you are addressing his point, though, that it is hard to integrate SWT classes with 
> many other JAVA classes.  It is likely you are not having to do that with Braille bBlaster, but I could 
> be wrong.  If I 
> >> am assuming incorrectly, let me know.
> >> 
> >> Best regards,
> >> 
> >> Steve Jacobson
> >> 
> >> 
> >> On Wed, 18 Jan 2012 11:00:03 -0600, John J. Boyer wrote:
> >> 
> >> >There is a version of SWT for each major platform. All you have to do is 
> >> >include the correct version in the lib subdirectory of your application. 
> >> >That is the approach we are lulsing in BrailleBlaster. We also have some 
> >> >native C libraries, which must be compiled for each platform, so SWT is 
> >> >no big deal. 
> >> 
> >> >There are limits to "compile once, run anywhere", IMHO. SWT will 
> >> >continue to be the best approach until <compile once, run anywhere," is 
> >> >applied to operating systems.
> >> 
> >> >John
> >> 
> >> >On Wed, Jan 18, 2012 at 09:48:53AM -0600, Steve Jacobson wrote:
> >> >> Dr. Richard Baldwin is working on a program that allows blind persons to draw based on commands 
> and he 
> >> >> has posted a number of messages on our BlindMath list.  I have long been frustrated by the 
> accessibility 
> >> >> of JAVA apps and one of my responses has been why don't more apps just use the SWT classes that 
> cause 
> >> >> JAVA apps to use the native controls of the operating system under which they run.  Dr. Baldwin 
> has used 
> >> >> these classes in his drawing program, and the results are pretty good.  However, he discussed the 
> >> >> difficulty of doing this in a note to the Blind Math list which I am including below.  I found his 
> >> >> comments to be both eye-opening and discouraging.
> >> >> 
> >> >> ==================BEGIN FORWARDED MESSAGE==================
> >> >> From: Richard Baldwin <baldwin at dickbaldwin.com>
> >> >> Date: Sun, 8 Jan 2012 07:59:46 -0600
> >> >> To: "Steve Jacobson" <steve.jacobson at visi.com>
> >> >> Subject: Re: [Blindmath] How useful is a GUI to blind users?
> >> >> 
> >> >> 
> >> >> You wrote: " Is it possible to use the SUN image API for the graphic
> >> >> presentation portions of the program and use SWT for the user controls? "
> >> >> 
> >> >> Just about anything is possible when enough programming effort is applied.
> >> >> What you suggest is possible but difficult to achieve in a reliable way,
> >> >> and quite a lot of extra programming effort is required to achieve it.
> >> >> However, that is not really the issue. The issue is that the use of the SWT
> >> >> precludes the use of many existing Java class libraries.
> >> >> 
> >> >> The great promise and benefit of object-oriented programming is "reuse,
> >> >> don't reinvent." The great power of the Java programming environment is the
> >> >> existence of massive class libraries that can be re-used to program with
> >> >> relative ease those things that would otherwise be very difficult.
> >> >> 
> >> >> The bottom line is that many existing Java class libraries cannot be
> >> >> "re-used" with the SWT without a major programming effort to modify those
> >> >> libraries. Even with a major programming effort, library modification is
> >> >> possible only when the author of the library is willing to divulge the
> >> >> source code for the library. Sometimes source code is available and
> >> >> sometimes it is not available.
> >> >> 
> >> >> IBM's approach with the SWT seems to have been "reinvent, don't reuse."
> >> >> They should not claim that their programming environment is Java simply
> >> >> because the compiled output will execute in a Java Virtual Machine. (The
> >> >> compiled output of JYthon and several other programming languages will also
> >> >> execute in a Java Virtual Machine but they are not Java.) IBM should have
> >> >> renamed their programming environment JBM or something like that to make it
> >> >> clear that SWT was never intended to be a member of the "write once, run
> >> >> anywhere" family of Java products and was never intended to be compatible
> >> >> with standard Java class libraries.
> >> >> 
> >> >> Microsoft did something similar a few years back, but after several years
> >> >> of floundering around with "Microsoft Java," they finally renamed their
> >> >> programming environment C# to distinguish it from Java. And, by going down
> >> >> an independent path from Java, developing their own class libraries, and
> >> >> not claiming any degree of compatibility with Java, C# has become a very
> >> >> respectable programming environment in its own right. IBM should do the
> >> >> same.
> >> >> 
> >> >> Welcome to the world of JBM.
> >> >> 
> >> >> Thanks for the response,
> >> >> Dick Baldwin
> >> >> 
> >> >> On Sun, Jan 8, 2012 at 5:55 AM, Larry Skutchan <lskutchan at aph.org> wrote:
> >> >> 
> >> >> > Is it possible to use the SUN image API for the graphic presentation
> >> >> > portions of the program and use SWT for the user controls? It doesn't seem
> >> >> > like either way provides any accessibility advantages to the graphical
> >> >> > drawing, manipulation, or interpretation portions of the interface, yet SWT
> >> >> > provides accessibility to those controls that do offer clear advantages for
> >> >> > both blind and sighted users.
> >> >> 
> >> >> 
> >> >> > On Jan 7, 2012, at 10:16 PM, Richard Baldwin wrote:
> >> >> 
> >> >> > > You wrote: " I thought there was generally a well-established principle
> >> >> > in
> >> >> > > software development that it is best to implement a set of functionality
> >> >> > in
> >> >> > > a way that can be connected to various presentations of user interface"
> >> >> > >
> >> >> > > You are probably speaking of something called the model-view-control
> >> >> > > pattern, which is great in theory, but rarely exists to the full extent
> >> >> > > possible in practice.
> >> >> > >
> >> >> > > Getting down in the weeds, here is an example of marrying Sun Java
> >> >> > graphics
> >> >> > > with SWT Java graphics. Standard Sun Java provides the capability to use
> >> >> > > the Sun Graphics2D API to create graphics on an off-screen Image object.
> >> >> > > Sun Graphics2D is a fairly extensive and powerful API.
> >> >> > >
> >> >> > > The SWT makes it possible to use SWT graphics (which are entirely
> >> >> > different
> >> >> > > from the Sun Graphics2D API) to create off-screen graphics on an Image
> >> >> > > object. In my opinion, SWT graphics are less extensive and less powerful
> >> >> > > than the Sun Graphics2D API, but that is just an opinion that others may
> >> >> > > disagree with. There is no disagreement, however, that the two are
> >> >> > > different and are incompatible.
> >> >> > >
> >> >> > > There is also no disagreement that an SWT Image object is different from
> >> >> > a
> >> >> > > Sun Image object, and the two are incompatible. Rather than building on
> >> >> > the
> >> >> > > Sun Image class, IBM elected to invent their own Image class in the SWT.
> >> >> > > This was a decision that apparently had nothing to do with the use of the
> >> >> > > native GUI components because it is not a GUI issue. Thus,
> >> >> > > incompatibilities between Sun Java and SWT Java go far deeper than simply
> >> >> > > the use of native GUI components or lightweight GUI components. They go
> >> >> > > very deep into the guts of the programming environment.
> >> >> > >
> >> >> > > When graphics are developed using Suns Graphics2D API, which is the case
> >> >> > > with the majority of existing Java graphics libraries, the display of
> >> >> > that
> >> >> > > graphic information on an SWT Composite object, requires that first, it
> >> >> > is
> >> >> > > necessary to gain access to the Sun Image object (if possible), then it
> >> >> > is
> >> >> > > necessary to reformat and transport the graphics information from the Sun
> >> >> > > Image object to an SWT Image object, and then it is necessary to display
> >> >> > > the graphics information on an SWT Composite object.
> >> >> > >
> >> >> > > To begin with, the graphics data on aSun Image object may, or may not be
> >> >> > > accessible to the programmer, depending on the design of the graphics
> >> >> > > library. Even if the graphics data on the Sun Image object is accessible
> >> >> > > (with or without modifying the library), the task of reformatting and
> >> >> > > transporting that data to an SWT Image object, solely for purposes of
> >> >> > > display, is tedious, time consuming, and can result in a lack of
> >> >> > > responsiveness for graphics-intensive programs.
> >> >> > >
> >> >> > > Of course, it is always possible to modify a library if source code for
> >> >> > the
> >> >> > > library is available, but to a large extent, that defeats the purpose of
> >> >> > > OOP and class libraries. It can also be very difficult in some cases.
> >> >> > >
> >> >> > > Dick Baldwin
> >> >> > >
> >> >> > > On Sat, Jan 7, 2012 at 7:57 PM, Jamal Mazrui <empower at smart.net> wrote:
> >> >> > >
> >> >> > >> Some miscellaneous points are as follows.
> >> >> > >>
> >> >> > >> There were text mode, screen oriented user interfaces before graphical
> >> >> > >> user interfaces, e.g., WordPerfect 5.1 was a highly popular DOS-based
> >> >> > word
> >> >> > >> processor among blind people.  In fact, I think we were, overall, more
> >> >> > >> productive with it than any GUI word processor, like MS Word,  or
> >> >> > >> command-oriented word processor, like VIM.
> >> >> > >>
> >> >> > >> Those text mode, screen oriented interfaces could be highly accessible
> >> >> > >> with a screen reader because it knew precisely what character (and
> >> >> > color)
> >> >> > >> was located in every position of a grid with 25 rows and 80 columns.
> >> >> >  The
> >> >> > >> point of focus was also precisely known -- what later became the caret
> >> >> > in a
> >> >> > >> GUI.  Accessibility of GUIs has been a problem in large part because a
> >> >> > >> screen reader has had to build an "off screen model" of what text is on
> >> >> > the
> >> >> > >> screen, since by the time text is displayed on the screen, it is pixels
> >> >> > not
> >> >> > >> characters.  A GUI screen reader has traditionally had to intercept
> >> >> > every
> >> >> > >> operating system call that writes to the screen, remember where the
> >> >> > writing
> >> >> > >> occurred, and adjust the model every time some other OS call implies a
> >> >> > >> change in the visual presentation.
> >> >> > >>
> >> >> > >> This process has been error prone, thus necessitating the need for an
> >> >> > >> accessibility API by which the screen reader can interrogate the screen
> >> >> > at
> >> >> > >> any time.  Unfortunately, comprehensively implementing that
> >> >> > accessibility
> >> >> > >> API, on both the application and screen reader side, has also been error
> >> >> > >> prone.  There are other reasons as well why GUIs have been difficult,
> >> >> > >> including the emphasis on a mouse for input rather than the keyboard --
> >> >> > the
> >> >> > >> former usually requiring fine eye-hand coordination to be practical.
> >> >> > >>
> >> >> > >> Blind people, like sighted people, have a range of cognitive abilities.
> >> >> > >> Some find the memorization of commands and syntax, which is generally
> >> >> > >> required by a command-line interface, to be challenging and
> >> >> > frustrating, as
> >> >> > >> compared to a GUI and screen reader combination implemented accessibly,
> >> >> > >> which support much more choice selection and safe exploration of options
> >> >> > >> before executing a task.  Often, the most productive application will be
> >> >> > >> one that offers both an accessible GUI for typical use and a
> >> >> > well-designed
> >> >> > >> command line interface for advanced use.
> >> >> > >>
> >> >> > >> I am puzzled why Swing seems to be so integrated into popular Java
> >> >> > >> libraries.  Do they not separate visual display from underlying
> >> >> > >> functionality?  I thought there was generally a well-established
> >> >> > principle
> >> >> > >> in software development that it is best to implement a set of
> >> >> > functionality
> >> >> > >> in a way that can be connected to various presentations of user
> >> >> > interface
> >> >> > >> -- unless, of course, the library is specifically targeted to building
> >> >> > user
> >> >> > >> interfaces.
> >> >> > >>
> >> >> > >> Regarding SWT, it is cross platform, not Windows only, though different
> >> >> > >> binary files have to be distributed with other platforms.  I am a fan of
> >> >> > >> wxWidgets, but agree that SWT is clearly more established in the Java
> >> >> > >> community, and do not see any advantage that wx-based GUIs would offer
> >> >> > over
> >> >> > >> SWT.  Both GUI libraries are essentially wrappers over native controls
> >> >> > of
> >> >> > >> the platform.  Such controls tend to be the most accessible because they
> >> >> > >> implement the primary accessibility API of the platform, being build by
> >> >> > the
> >> >> > >> developer of both the platform and accessibility API.
> >> >> > >>
> >> >> > >> Jamal
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> ______________________________**_________________
> >> >> > >> Blindmath mailing list
> >> >> > >> Blindmath at nfbnet.org
> >> >> > >> http://nfbnet.org/mailman/**listinfo/blindmath_nfbnet.org<
> >> >> > http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org>
> >> >> > >> To unsubscribe, change your list options or get your account info for
> >> >> > >> Blindmath:
> >> >> > >> http://nfbnet.org/mailman/**options/blindmath_nfbnet.org/**
> >> >> > >> baldwin%40dickbaldwin.com<
> >> >> > http://nfbnet.org/mailman/options/blindmath_nfbnet.org/baldwin%40dickbaldwin.com
> >> >> > >
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Richard G. Baldwin (Dick Baldwin)
> >> >> > > Home of Baldwin's on-line Java Tutorials
> >> >> > > http://www.DickBaldwin.com
> >> >> > >
> >> >> > > Professor of Computer Information Technology
> >> >> > > Austin Community College
> >> >> > > (512) 223-4758
> >> >> > > mailto:Baldwin at DickBaldwin.com
> >> >> > > http://www.austincc.edu/baldwin/
> >> >> > > _______________________________________________
> >> >> > > Blindmath mailing list
> >> >> > > Blindmath at nfbnet.org
> >> >> > > http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
> >> >> > > To unsubscribe, change your list options or get your account info for
> >> >> > Blindmath:
> >> >> > >
> >> >> > http://nfbnet.org/mailman/options/blindmath_nfbnet.org/lskutchan%40aph.org
> >> >> 
> >> >> 
> >> >> > _______________________________________________
> >> >> > Blindmath mailing list
> >> >> > Blindmath at nfbnet.org
> >> >> > http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
> >> >> > To unsubscribe, change your list options or get your account info for
> >> >> > Blindmath:
> >> >> 
> >> >> > http://nfbnet.org/mailman/options/blindmath_nfbnet.org/baldwin%40dickbaldwin.com
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >> -- 
> >> >> Richard G. Baldwin (Dick Baldwin)
> >> >> Home of Baldwin's on-line Java Tutorials
> >> >> http://www.DickBaldwin.com
> >> >> 
> >> >> Professor of Computer Information Technology
> >> >> Austin Community College
> >> >> (512) 223-4758
> >> >> mailto:Baldwin at DickBaldwin.com
> >> >> http://www.austincc.edu/baldwin/
> >> >> _______________________________________________
> >> >> ===================END FORWARDED MESSAGE===================
> >> >> 
> >> >> 
> >> >> 
> >> >> 
> >> >> _______________________________________________
> >> >> nfbcs mailing list
> >> >> nfbcs at nfbnet.org
> >> >> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> >> >> To unsubscribe, change your list options or get your account info for nfbcs:
> >> >> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/john.boyer%40abilitiessoft.com
> >> 
> >> >-- 
> >> >John J. Boyer; President, Chief Software Developer
> >> >Abilitiessoft, Inc.
> >> >http://www.abilitiessoft.com
> >> >Madison, Wisconsin USA
> >> >Developing software for people with disabilities
> >> 
> >> 
> >> >_______________________________________________
> >> >nfbcs mailing list
> >> >nfbcs at nfbnet.org
> >> >http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> >> >To unsubscribe, change your list options or get your account info for nfbcs:
> >> >http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/steve.jacobson%40visi.com
> >> 
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> nfbcs mailing list
> >> nfbcs at nfbnet.org
> >> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> >> To unsubscribe, change your list options or get your account info for nfbcs:
> >> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/john.boyer%40abilitiessoft.com
> 
> >-- 
> >John J. Boyer; President, Chief Software Developer
> >Abilitiessoft, Inc.
> >http://www.abilitiessoft.com
> >Madison, Wisconsin USA
> >Developing software for people with disabilities
> 
> 
> >_______________________________________________
> >nfbcs mailing list
> >nfbcs at nfbnet.org
> >http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> >To unsubscribe, change your list options or get your account info for nfbcs:
> >http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/steve.jacobson%40visi.com
> 
> 
> 
> 
> 
> _______________________________________________
> nfbcs mailing list
> nfbcs at nfbnet.org
> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> To unsubscribe, change your list options or get your account info for nfbcs:
> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/john.boyer%40abilitiessoft.com

-- 
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities

More information about the NFBCS mailing list