[brailleblaster] Re: Some Thoughts
- From: Alex Jurgensen <asquared21@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Wed, 2 Feb 2011 16:30:51 -0800
Hi,
My main issue is that we are forcing developers to include JRE's with their
software.
I myself think C++ is better for this task, since, as I stated before, LibLouis
is already written in C. We also have WX-Widgets for C++.
Why don't we abstract the core into C or C++ and do the UI in whatever else is
most accessible. With LibLouis and the other translation package in C already,
this should not be too difficult and gives us, as a project, many advantages.
By doing it this way, we would open up use of our framework/engine by
developers who are used to using other languages, through the use of wrappers,
if necessary.
Here is an example.
As an independent developer myself, I was hoping that I could extend BB to
integrate natively with some of my OS's more specialized features. Both Mac OS
X and Linux have a lot to offer, but I wouldn't go as far as bundling a JRE
just to get the advantage of a BB powered engine, since, with a little bit more
work, I could use LibLouis and the other translation package without any need
for a JRE.
This would be a shame, as I would be willing to help contribute to BB as a
framework.
This example situation is one that I can see BB running up against. Although I
just gave that as an example and I am not saying that I would or would use BB
or contribute to BB in this manner, I can see a lot of time being wasted by
developers who reinvent the wheel.
I think we can avoid this by doing as I suggested.
Any contributions to BB are very important in my opinion, and we cannot afford
to miss out on these opportunities.
Just my thoughts.
Regards,
Alex,
Alex Jurgensen,
VoiceOver Trainer,
Visit me on the web at: http://www.vipbc.org/
On 2011-02-02, at 3:56 PM, Michael Whapples wrote:
> My short answer is, "get over your problems with Java, it can interface with
> native system libraries if you want to do that". So others would be equally
> as able to enhance BrailleBlaster if it is written in Java or any other
> language, probably what matters more for customisation is the quality of the
> design. The arguments of what happens if Oracle were to ditch Java and so
> JRE's were hard to come by (an unlikely case I think, Oracle has a number of
> there software packages in Java and others could continue development of the
> JDK now Java is opensource in the form of the OpenJDK), well that applies as
> much to other programming languages, what if Apple feel that Python isn't
> worth supporting (they are behind the latest Python version by a bit), Ruby
> needs an interpreter, ocaml needs a compiler, what if Apple decided they
> could do better than objective-c as their main development language, etc.
> Java has a number of large companies behind it, including Apple (they are
> contributing to the Mac port of OpenJDK), so where's the evidence of death of
> Java?
>
> I will just add, actually python got some consideration near the beginning. I
> certainly like python, its great for quickly getting things done. The problem
> in python is the GUI support, it probably would have required separate GUI
> modules for each platform and this very well could have eaten back the
> advantages of python being really easy to work in.
>
> Michael Whapples
> On 02/02/11 23:45, Alex Jurgensen wrote:
>> Hi,
>>
>> What about C++, C, Rubie, or any of the other "First Class" languages.
>>
>> If we as a project built the generic UI and then left the door open to third
>> parties to create their own UI's, who knows, we may end up with hands-free
>> Braille translation software or a version of BB that only embosses for
>> certain people, using facial recognition.
>>
>> I know these are far fetched ideas, but there is a lot of potential to go
>> above and beyond the specification.
>>
>> For instance, what if a third-party made a mobile version of BB that could
>> sync with a modified desktop version for embossing?
>>
>> This is what we gain by making an engine that is robust and is written in
>> something that is easy to integrate with other programming languages through
>> wrappers or natively.
>>
>> Regards,
>> Alex,
>>
>>
>> On 2011-02-02, at 3:30 PM, qubit wrote:
>>
>>> Hi Alex --
>>> you want to component out a braille translation engine separate from the
>>> UI -- I believe that is already the case as braille translation and
>>> back-translation is being handled almost completely by JohnB's C libraries.
>>> Your arguments are compelling (you almost had me convinced about objective
>>> C), but I think that it is not used nearly as widely as java, and its future
>>> depends on Apple's projections to take over the world as we know it *smile*
>>> I also think that separating out a language-independent way of expressing
>>> the UI is awkward and prone to bias.
>>> I think that some work could be done to produce a layer of code between the
>>> liblouis* libraries and the UI to flesh out whatever is put in the
>>> requirements, but I'm still not convinced that ditching java is the best
>>> approach.
>>> Just my $0.02.
>>> --le
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Alex Jurgensen"<asquared21@xxxxxxxxx>
>>> To:<brailleblaster@xxxxxxxxxxxxx>
>>> Sent: Wednesday, February 02, 2011 4:42 PM
>>> Subject: [brailleblaster] Re: Some Thoughts
>>>
>>>
>>> Hi,
>>>
>>> To answer your questions, I don't dislike Java in any way.
>>>
>>> I am just looking into the future. With Microsoft roomered to launch an apps
>>> store with Windows 8, and Apple having successfully launched two so far, I
>>> think that we must look at the direction the market is heading and not just
>>> at what would work right now.
>>>
>>> I started my development in Java and continue to have plans for some
>>> projects in Java, but I think that Java has its place, as does any
>>> programming language.
>>>
>>> As to Macs representing a very small number of users, I would have to agree
>>> over all, but disagree that we can afford to ignore the platform.
>>>
>>> It is gaining in popularity among blind users.
>>>
>>> Let's say that tomorrow all desktops disappeared. What would run BB, a
>>> handful of tablets?
>>>
>>> As computers evolve, we can't live in the desktop paridyme. We must flow
>>> with the market.
>>>
>>> My suggestion of using a natively compiled language would allow us to secure
>>> against changes in the UI that we can't predict today.
>>>
>>> I suggest that we component out BB into a Braille translation engine with a
>>> UI as a separate component.
>>>
>>> Then, if Viewplus drops support for a platform, it would be straight forward
>>> for another group to pick it up.
>>>
>>> I know the same can be said for writing the logic in Java, but I think that
>>> Java is a weakness in the structure of BB.
>>>
>>> There are two main reasons for this.
>>>
>>> Embedded distros may not support Linux and although they form a very small
>>> percent of the market today, may form a bigger percentage tomorrow.
>>>
>>> Secondly, it relies on a JVM, which not only can use more resources, but,
>>> even if the issue of efficiency could be worked around, would rely on JRE's
>>> being maintained.
>>>
>>> Just my thoughts.
>>>
>>> Regards,
>>> Alex,
>>>
>>> Alex Jurgensen,
>>> VoiceOver Trainer,
>>>
>>> Visit us on the web at: http://www.vipbc.org/
>>>
>>>
>>> On 2011-02-02, at 1:56 PM, Michael Whapples wrote:
>>>
>>>> I am going to be direct, you keep bringing it up and honesty may be the
>>>> only way to get to the bottom of it.
>>>>
>>>> I am getting the feeling your issue is not really with SWT but rather with
>>>> Java. What is it about Java you don't like?
>>>>
>>>> As an example to why I draw the conclusion above, you say use
>>>> C/C++/objective-c for logic code but possibly use SWT for the UI. The
>>>> rationale you give for this is to have the possibility of being able to
>>>> develop a native GUI for the Mac. Well having the logic code in Java also
>>>> would allow for that as I have pointed out in the past. Java can access
>>>> native code and so use the platform's native GUI libraries directly. The
>>>> example I have given before is cyberduck http://www.cyberduck.ch, which in
>>>> fact Apple have put in their list of applications accessible with
>>>> voiceover http://www.apple.com/accessibility/voiceover/applications.html,
>>>> look under utilities.
>>>>
>>>> I won't say my views on the app store again, other than to mention, Macs
>>>> only represent a small number of users, as Linux probably does, and so
>>>> technologies of one platform, particularly optional ones which the app
>>>> store seems to be, should not drive the direction of the project.
>>>>
>>>> I guess the last say on all this could and probably does fall back to
>>>> ViewPlus, who are the ones wanting this project. How important is the Mac
>>>> to ViewPlus? What is the minimum acceptable standard of support for the
>>>> Mac? Oh, and I am not getting at the Macs here,the same questions should
>>>> be asked for the other platforms.
>>>>
>>>> Michael Whapples
>>>> On 02/02/11 17:49, Alex Jurgensen wrote:
>>>>> Hi,
>>>>>
>>>>> If we use the web approach, we can style the applcations to look like
>>>>> native Mac apps.
>>>>>
>>>>> These are the headaches that just kill me about cross-platform stuff.
>>>>>
>>>>> If we only wrote hte main logic in something like C, Objective-C or C++
>>>>> and then did our UI's in SWT, that would at least give us the possibility
>>>>> to write an alternative UI down the road for the Mac.
>>>>>
>>>>> Regards,
>>>>> Alex,
>>>>>
>>>>>
>>>>> On 2011-02-02, at 9:41 AM, Chris von See wrote:
>>>>>
>>>>>> Highly unlikely - rule 2.24
>>>>>> ofhttp://stadium.weblogsinc.com/engadget/files/mac-app-review.pdf seems
>>>>>> pretty clear:
>>>>>>
>>>>>> 2.24 Apps that use deprecated or optionally installed technologies
>>>>>> (e.g., Java, Rosetta) will be rejected
>>>>>>
>>>>>> You *may* be able to get around the rules regarding deprecated
>>>>>> technologies by bundling a JRE (it would almost certainly need to be
>>>>>> SoyLatte since you can't include anything with a third-party installer
>>>>>> such as an Oracle JRE for Mac). You almost certainly will not be able
>>>>>> to get around the requirement that the UI adhere to the Mac Human
>>>>>> Interface Guidelines - Java apps that don't use Apple's enhanced JRE
>>>>>> look nothing like native Mac apps.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 2, 2011, at 9:29 AM, Alex Jurgensen wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I realize that.
>>>>>>>
>>>>>>> However, I think that including a JDK might solve this.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alex,
>>>>>>>
>>>>>>>
>>>>>>> On 2011-02-02, at 9:28 AM, Chris von See wrote:
>>>>>>>
>>>>>>>> Java applications cannot be included in the Mac App Store. Java is
>>>>>>>> now considered to be an "optional" technology on the Mac, according to
>>>>>>>> Apple.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 2, 2011, at 9:21 AM, Alex Jurgensen wrote:
>>>>>>>>
>>>>>>>>> Hi John,
>>>>>>>>>
>>>>>>>>> I was refering more to Chris' message about using STW's browser
>>>>>>>>> control as a UI. That would get us half way to having a web app,
>>>>>>>>> would it not.
>>>>>>>>>
>>>>>>>>> Now, that depends on how we end up doing the UI.
>>>>>>>>>
>>>>>>>>> About the auto updater, I am working on it because this is where I
>>>>>>>>> feel the most confident, creating a boot loader.
>>>>>>>>>
>>>>>>>>> Here is my question.
>>>>>>>>>
>>>>>>>>> How far along are we in the 2 year development cycle? The website
>>>>>>>>> does not list a date that the project was started on.
>>>>>>>>>
>>>>>>>>> I have also been investigating the rules for submitting the
>>>>>>>>> application through Apple's Mac App Store.
>>>>>>>>>
>>>>>>>>> I know it is a little early for this, but I have read about
>>>>>>>>> developers who wrote entire applications that got rejected because of
>>>>>>>>> something that was too difficult to change at the time of submission.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alex,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2011-02-02, at 9:13 AM, John J. Boyer wrote:
>>>>>>>>>
>>>>>>>>>> Alex,
>>>>>>>>>>
>>>>>>>>>> Sorry about the need to modify your application bundle, but
>>>>>>>>>> BrailleBlaster has always been written as one word.
>>>>>>>>>>
>>>>>>>>>> I think you are getting ahead of us. It is too early to include
>>>>>>>>>> auto-updatre, and a web application is a whold divverent project. We
>>>>>>>>>> have to stick to what we are doing. After BrailleBlaster is working
>>>>>>>>>> as a
>>>>>>>>>> desktop application we can consider a Web application.
>>>>>>>>>>
>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 02, 2011 at 08:52:17AM -0800, Alex Jurgensen wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I suppose that the Mac issues should be resolved in any case. This
>>>>>>>>>>> would help the Mac community as a whole.
>>>>>>>>>>>
>>>>>>>>>>> I've built my boot loader now, but I can't test it yet.
>>>>>>>>>>>
>>>>>>>>>>> Did you get a chance to look at my mock up yet?
>>>>>>>>>>>
>>>>>>>>>>> What do you think of it?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alex,
>>>>>>>>>>>
>>>>>>>>>>> Alex Jurgensen,
>>>>>>>>>>> VoiceOver Trainer,
>>>>>>>>>>>
>>>>>>>>>>> Visit me on the web at:http://www.vipbc.org/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2011-02-02, at 12:19 AM, John J. Boyer wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I've read through all these messages, and I'm convinced we should
>>>>>>>>>>>> stick
>>>>>>>>>>>> with SWT. By the time BrailleBlaster is ready for use by anybody
>>>>>>>>>>>> other
>>>>>>>>>>>> than a developer the problems on the Mac may be resolved. We can
>>>>>>>>>>>> add a
>>>>>>>>>>>> little pressure to the Eclipse developers to help things along.
>>>>>>>>>>>> The idea
>>>>>>>>>>>> of using the SWT browser to present GUI content is interesting.
>>>>>>>>>>>>
>>>>>>>>>>>> The classpaths specified in the ant build.xml file go iknto the
>>>>>>>>>>>> manifest
>>>>>>>>>>>> of the BrailleBlaster jar file. This makes callinng BrailleBlaster
>>>>>>>>>>>> very
>>>>>>>>>>>> convenient on my flavor of Linux and on Windows. We could make
>>>>>>>>>>>> different
>>>>>>>>>>>> versions of BrailleBlaster for different distros, but I think that
>>>>>>>>>>>> is
>>>>>>>>>>>> something for the early adapters who use these distros to worry
>>>>>>>>>>>> about.
>>>>>>>>>>>> They will know their own flavors. And many of them won't care
>>>>>>>>>>>> about the
>>>>>>>>>>>> standard locations.
>>>>>>>>>>>>
>>>>>>>>>>>> Let's learn from Alex's experience in proting BrailleBlaster to
>>>>>>>>>>>> the Mac.
>>>>>>>>>>>> Concern about various Linux flavors at this time is a distraction.
>>>>>>>>>>>>
>>>>>>>>>>>> As for me, I'm concentrating on getting BrailleBlaster to work
>>>>>>>>>>>> with at
>>>>>>>>>>>> least generic embossers. Then I'll make a simple text editor using
>>>>>>>>>>>> a
>>>>>>>>>>>> GUI. the experience in doing this will be necessary to make the
>>>>>>>>>>>> real
>>>>>>>>>>>> GUI. The text editor will remain as a BrailleBlaster feature to be
>>>>>>>>>>>> used
>>>>>>>>>>>> by advanced users.
>>>>>>>>>>>>
>>>>>>>>>>>> Incidentally, BrailleBlaster is a single word. It should not have
>>>>>>>>>>>> a
>>>>>>>>>>>> space.
>>>>>>>>>>>>
>>>>>>>>>>>> John
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> John J. Boyer; President, Chief Software Developer
>>>>>>>>>>>> Abilitiessoft, Inc.
>>>>>>>>>>>> http://www.abilitiessoft.com
>>>>>>>>>>>> Madison, Wisconsin USA
>>>>>>>>>>>> Developing software for people with disabilities
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- End forwarded message -----
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> John J. Boyer; President, Chief Software Developer
>>>>>>>>>>>> Abilitiessoft, Inc.
>>>>>>>>>>>> http://www.abilitiessoft.com
>>>>>>>>>>>> Madison, Wisconsin USA
>>>>>>>>>>>> Developing software for people with disabilities
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> John J. Boyer; President, Chief Software Developer
>>>>>>>>>> Abilitiessoft, Inc.
>>>>>>>>>> http://www.abilitiessoft.com
>>>>>>>>>> Madison, Wisconsin USA
>>>>>>>>>> Developing software for people with disabilities
>>>>>>>>>>
>>>>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Other related posts:
