[jawsscripts] Re: Another public beta of JAWS Script Exchange 2.0

Thanks for your interest in JSX.  Below is an excerpt from the current
documentation.  The merging capability is an advanced option that is a
bit hard to explain, unfortunately.  I'll gladly answer questions
though, and if I discover that something desirable is not possible, I'll
try to enhance the feature.  I'd be glad to work with the author of the
Twitter scripts if he wants to build a JSX-based installer for them.

Jamal

JSX 1.4 introduced a second, usually better way of merging.  In this
example, the file HomerIE.jss contains enhancements to the Internet
Explorer scripts supplied with JAWS.  Place the following line at the
top of the file:

;Merge "BrowseUI"

This tells JSX to merge HomerIE.jss into the script set associated with
the base name BrowsUI (the file name is BrowseUI.dll).  JSX looks up the
association in ConfigNames.ini.  With JAWS 8 and above, the main file of
the script set is "Internet Explorer.jss."  With lower JAWS versions, it
is "Internet Explorer 5-6.jss."

JSX creates a container file with a set of Use statements that load
script components in a particular order, thereby governing the
inheritance chain of scripts and functions.  The file also contains a
dummy function at the bottom, which is needed so that the JAWS script
compiler considers the file to be a valid script file, thus creating a
valid .jsb version after compilation.  The factory-supplied version of
the .jsb is copied from the All Users script folder to a file in the
user script folder with a modified name.  A suffix of _fs (standing for
Freedom Scientific) is added to the base name, e.g., Internet
Explorer.jsb would become Internet Explorer_fs.jsb, or default.jsb would
become default_fs.jsb.

The order of Use statements in the generated container file is
determined by the following algorithm.  If there is an existing
container file, its component order is the starting sequence; otherwise
it is an empty string.  If there is a vertical bar (|) delimited list of
components after the Merge word on the top line, its sequence is
appended to the starting sequence after removing any duplicate items
from the starting sequence.  If the resulting sequence does not contain
the _fs component, it is prepended to the sequence (so it serves as base
functionality at the top level of the inheritance chain).  If the
current script component is not contained in the sequence, it is
appended.

In our example, a container file called Internet Explorer.jss would be
created and compiled with the following content:

; This is a container file, structured with conventions to support
merging by the JAWS Script Exchange program.
; Rather than code of its own, the file contains a sequence of Use
statements, followed by a dummy function to satisfy the JAWS script
compiler.

Use "Internet Explorer_fs.Jsb"
Use "HomerIE.jsb"

Void Function _Filler()
SayString("This is to complete a container .jss so that it compiles to a
valid .jsb")
EndFunction


Suppose we wanted to add AnotherIE.jsb to the sequence.  We could do so
with the following syntax on the top line:

;Merge AnotherIE.jsb "BrowseUI"

Now the container file would begin with the following statements:

Use "Internet Explorer_fs.Jsb"
Use "AnotherIE.jsb"
Use "HomerIE.jsb"

The merge algorithm is intended to accomplish several objectives:

* Previous JSX syntax for merging remains compatible.

*  If no container file already exists, the component sequence will be
the _FS file followed by the current file.

*  If a container file already exists and no post sequence is specified,
the existing sequence will be preserved.

*  If a post sequence is specified, it can override the existing
sequence.

JSX would also merge related .jkm and .jcf files, which are in .ini
format, as follows.  It iterates through all sections of the new file,
and all keys within each section, writing the key/value pair to the
existing file.  Thus, if a key already exists, its value is replaced.
If it does not already exist, it is created.

The merge target may be a delimited list of files rather than a single
file, e.g.,

;Merge "BrowseUI|IEFrame"

If a question mark follows the semicolon, JSX asks for confirmation
about whether to perform the merge, prompting with a warning on the
remainder of the line, e.g.,

;?Merge "Microsoft Outlook.jss|Microsoft Outlook XP-2003.jss" For Homer
benefits that require configuring Outlook for plain text email,

On Tue, 24
Feb 2009, Donald Marang wrote:

> Date: Tue, 24 Feb 2009 11:08:57 -0500
> From: Donald Marang <donald.marang@xxxxxxxxx>
> Reply-To: jawsscripts@xxxxxxxxxxxxx
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange 2.0
>
> Hey Jamal,
>
> Sorry for the ignorance in the use of your exchange software as a developer
> and the automation of the "merge" process!  I plan to use it soon for my
> Verizon project and others.  I downloaded the version several months ago,
> but have not yet taken the time  to learn your program or use it.  I guess I
> will need to visit your site again and check out your new beta version.  Is
> there any documentation for these conventions you talk about for the Use
> statement and container script files available anywhere?  I hope I have
> followed them to this point.  I think my next release will have two
> application script files and two container script files.  One of the user
> default container script file has a key map file I would like to
> automatically merge with the default key map file.  Of course, both
> container script files have a Use statements that need to be merged.  Is
> this possible?  If it is, I am surprised that the merge features of your
> exchange program were not used for an interesting new set of scripts,
> "Jawter".  This looks like a fantastic container script file to monitor
> Twitter activity and respond without ever running any application.  His
> scripts do it all from any application!  I am now considering getting a
> Twitter account just to check it out.  It can be found at:
> http://randylaptop.com/
>
> I discovered it on an MP3 podcast on the BlindCoolTech RSS feed at:
> http://feeds.feedburner.com/blindcooltech
>
> Thanks.
>
> Don Marang
>
>
> ----- Original Message -----
> From: "Jamal Mazrui" <empower@xxxxxxxxx>
> To: <jawsscripts@xxxxxxxxxxxxx>
> Sent: Monday, February 23, 2009 1:53 PM
> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange 2.0
>
>
> > Thanks for more detail.  I'll reflect on this to possibly make it more
> > flexible.  Since there is not a defined API for merging files, however,
> > I think the best solution involves following conventions.  If the
> > scripter knows that JSX expects a certain organization for a container.jss
> > file, then he or she can make sure to place Use statements
> > above the dummy function, and to put additional code in a .jsb that is
> > referenced by a Use statement.  I do want to try to ensure that complete
> > functionality is possible with these conventions, however, so if you
> > think of a situation that cannot be accommodated successfully by this
> > organization, let me know.
> >
> > Jamal
> > On Mon, 23 Feb 2009, Bryan Garaventa wrote:
> >
> >> Date: Mon, 23 Feb 2009 10:32:43 -0800
> >> From: Bryan Garaventa <bgaraventa11@xxxxxxxxxxxxxx>
> >> Reply-To: jawsscripts@xxxxxxxxxxxxx
> >> To: jawsscripts@xxxxxxxxxxxxx
> >> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange
> >> 2.0
> >>
> >> My only concern is that there appears to be a loop hole for data loss,
> >> this
> >> area being for anything below the dummy function. For instance, if the
> >> user
> >> were to add their own Use statement, but instead of adding this at the
> >> top
> >> of the page, they added it to the bottom instead. Also, if the user were
> >> to
> >> add their own function or script to this default.jss file at a later
> >> date,
> >> it too would be broken if this code is not included in the merge.
> >> If there was a way to keep all of the current dummy jss content and add
> >> the
> >> new Use statement without the risk of any data loss, the whole process
> >> would
> >> be continually seamless. Sorry if I wasn't too clear earlier.
> >>
> >> ----- Original Message -----
> >> From: "Jamal Mazrui" <empower@xxxxxxxxx>
> >> To: <jawsscripts@xxxxxxxxxxxxx>
> >> Sent: Monday, February 23, 2009 9:48 AM
> >> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange
> >> 2.0
> >>
> >>
> >> > Are you talking about a container type of .jss file?  By this, I mean
> >> > one with no significant code of its own -- basically, a list of Use
> >> > statements followed by a dummy function.  If JSX finds a dummy function
> >> > with the conventional name, it does recognize references to the .jsb
> >> > that is about to be merged, and does not duplicate such a reference.
> >> >
> >> > I want to better understand what you are hoping to achieve.  Is the a
> >> > problem with organizing a .jss so that it follows the JSX conventions
> >> > for
> >> > a container.jss file?
> >> >
> >> > Jamal
> >> > On Mon, 23 Feb 2009, Bryan Garaventa wrote:
> >> >
> >> >> Date: Mon, 23 Feb 2009 09:38:06 -0800
> >> >> From: Bryan Garaventa <bgaraventa11@xxxxxxxxxxxxxx>
> >> >> Reply-To: jawsscripts@xxxxxxxxxxxxx
> >> >> To: jawsscripts@xxxxxxxxxxxxx
> >> >> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange
> >> >> 2.0
> >> >>
> >> >> No problem,
> >> >>
> >> >> Is it possible to use a Find String command to see if the currently
> >> >> merged
> >> >> Use statement is already present in the default.jss file?
> >> >>
> >> >> If Void Function _Filler() was not detected at this time, then the new
> >> >> default.jss file could be generated as it currently is.
> >> >>
> >> >> If the Void Function _Filler() is found though, but the new Use
> >> >> statement
> >> >> is
> >> >> not, then the new Use statement could be prepended to the top of the
> >> >> complete default.jss file and compiled.
> >> >>
> >> >> If it were done in such a way, you would never have to be concerned
> >> >> about
> >> >> any data loss, even if the user wrote their own functions and added
> >> >> these
> >> >> to
> >> >> the new default.jss file. It would just keep on working regardless, no
> >> >> matter how many times the same installer, or different installers for
> >> >> different scripts were used.
> >> >>
> >> >> Do you think this might be possible?
> >> >>
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Jamal Mazrui" <empower@xxxxxxxxx>
> >> >> To: <jawsscripts@xxxxxxxxxxxxx>
> >> >> Sent: Monday, February 23, 2009 7:23 AM
> >> >> Subject: [jawsscripts] Re: Another public beta of JAWS Script Exchange
> >> >> 2.0
> >> >>
> >> >>
> >> >> > Thanks for your feedback, Bryan, as I want to finalize this version
> >> >> > of
> >> >> > JSX.  It should treat default.jss as you intend if it contains a
> >> >> > dummy
> >> >> > function with a particular naming convention for this purpose, which
> >> >> > I
> >> >> > recall adoptingg from Doug Lee.  If JSX finds the following line in
> >> >> > a
> >> >> > .jss
> >> >> > merge target:
> >> >> >
> >> >> > Void Function _Filler()
> >> >> >
> >> >> > it assumes the .jss is a container file with Use statements above
> >> >> > that
> >> >> > dummy function, and nothing significant afterward.  If that does not
> >> >> > work,
> >> >> > let me know.
> >> >> >
> >> >> > Jamal
> >> >> > On Sat, 21 Feb 2009, Bryan Garaventa wrote:
> >> >> >
> >> >> >> Date: Sat, 21 Feb 2009 21:35:14 -0800
> >> >> >> From: Bryan Garaventa <bgaraventa11@xxxxxxxxxxxxxx>
> >> >> >> Reply-To: jawsscripts@xxxxxxxxxxxxx
> >> >> >> To: jawsscripts@xxxxxxxxxxxxx
> >> >> >> Subject: [jawsscripts] Re: Another public beta of JAWS Script
> >> >> >> Exchange
> >> >> >> 2.0
> >> >> >>
> >> >> >> Hi Jamal, I was finally able to try out the new version, and it's
> >> >> >> working
> >> >> >> much better than it used to. Excellent!
> >> >> >>
> >> >> >> Only one thing though, is there any way to make the string parser
> >> >> >> detect
> >> >> >> pre-existing use statements within the default.jss file as well?
> >> >> >> For
> >> >> >> instance, I use a lot of internal use statements for projects I
> >> >> >> develop
> >> >> >> at
> >> >> >> different times, and I always use the use statement to reference
> >> >> >> these
> >> >> >> script sets during development. Plus some of my scripts depend on
> >> >> >> the
> >> >> >> addition of the use statement, such as the online chat page scripts
> >> >> >> at
> >> >> >> http://gutterstar.net/dynamic_live_chat.php
> >> >> >> So the static use of specific use statements within the installer
> >> >> >> can't
> >> >> >> always be relied upon to keep these custom use statements as well.
> >> >> >>
> >> >> >> I'm unfamiliar with the programming language used for this purpose
> >> >> >> within
> >> >> >> the installer, but would it be possible to parse the string content
> >> >> >> line
> >> >> >> by
> >> >> >> line for default.jss, and save or copy all of the statements
> >> >> >> beginning
> >> >> >> with
> >> >> >> Use for inclusion within the new Default.jss output file? Please
> >> >> >> forgive
> >> >> >> my
> >> >> >> ignorance if this is more complicated than I understand. This
> >> >> >> really
> >> >> >> is a
> >> >> >> great product, and you've done a great job.
> >> >> >>
> >> >> >>  Best wishes,
> >> >> >>
> >> >> >> Bryan
> >> >> >>
> >> >> >> ----- Original Message -----
> >> >> >> From: "Jamal Mazrui" <empower@xxxxxxxxx>
> >> >> >> To: <jawsscripts@xxxxxxxxxxxxx>
> >> >> >> Sent: Monday, February 16, 2009 8:23 AM
> >> >> >> Subject: [jawsscripts] Another public beta of JAWS Script Exchange
> >> >> >> 2.0
> >> >> >>
> >> >> >>
> >> >> >> > http://EmpowermentZone.com/jsxsetup.exe
> >> >> >> >
> >> >> >> > This version enhances merge support, and bundles optional script
> >> >> >> > sets.
> >> >> >> > The JSX installer engine now recognizes an existing container.jss
> >> >> >> > file
> >> >> >> > that it previously created, a script file containing a set of Use
> >> >> >> > statements followed by a dummy function to satisfy the JAWS
> >> >> >> > script
> >> >> >> > compiler.  A merge operation incorporates the components
> >> >> >> > referenced
> >> >> >> > in
> >> >> >> > such a file.
> >> >> >> >
> >> >> >> > At the end of the installation process for the complete JSX
> >> >> >> > application
> >> >> >> > (using the above URL), three script sets are offerred.  These
> >> >> >> > options
> >> >> >> > are
> >> >> >> > unchecked by default.  You can check one ore more of them to
> >> >> >> > install
> >> >> >> > their
> >> >> >> > zip archives with JSX.. i.e.,
> >> >> >> >
> >> >> >> > BX, the Jaws toolbox by Doug Lee (BSD license)
> >> >> >> >
> >> >> >> > HomerKit, the Homer script library and editor interface by Jamal
> >> >> >> > Mazrui
> >> >> >> > (LGPL license)
> >> >> >> >
> >> >> >> > Visual Studio scripts by contributors from the blind programming
> >> >> >> > community
> >> >> >> > (public domain)
> >> >> >> >
> >> >> >> > Jamal
> >> >> >> >
> >> >> >> > __________
> >> >> >> > Visit and contribute to The JAWS Script Repository
> >> >> >> > http://jawsscripts.com
> >> >> >> >
> >> >> >> > View the list's information and change your settings at
> >> >> >> > http://www.freelists.org/list/jawsscripts
> >> >> >> >
> >> >> >> >
> >> >> >> > _______________________________________
> >> >> >> > No viruses found in this incoming message
> >> >> >> > Scanned by iolo AntiVirus 1.5.6.3
> >> >> >> > http://www.iolo.com
> >> >> >> >
> >> >> >>
> >> >> >> __________
> >> >> >> Visit and contribute to The JAWS Script Repository
> >> >> >> http://jawsscripts.com
> >> >> >>
> >> >> >> View the list's information and change your settings at
> >> >> >> http://www.freelists.org/list/jawsscripts
> >> >> >>
> >> >> > __________
> >> >> > Visit and contribute to The JAWS Script Repository
> >> >> > http://jawsscripts.com
> >> >> >
> >> >> > View the list's information and change your settings at
> >> >> > http://www.freelists.org/list/jawsscripts
> >> >> >
> >> >>
> >> >> __________
> >> >> Visit and contribute to The JAWS Script Repository
> >> >> http://jawsscripts.com
> >> >>
> >> >> View the list's information and change your settings at
> >> >> http://www.freelists.org/list/jawsscripts
> >> >>
> >> > __________
> >> > Visit and contribute to The JAWS Script Repository
> >> > http://jawsscripts.com
> >> >
> >> > View the list's information and change your settings at
> >> > http://www.freelists.org/list/jawsscripts
> >> >
> >>
> >> __________
> >> Visit and contribute to The JAWS Script Repository http://jawsscripts.com
> >>
> >> View the list's information and change your settings at
> >> http://www.freelists.org/list/jawsscripts
> >>
> > __________
> > Visit and contribute to The JAWS Script Repository http://jawsscripts.com
> >
> > View the list's information and change your settings at
> > http://www.freelists.org/list/jawsscripts
> >
>
> __________ 
> Visit and contribute to The JAWS Script Repository http://jawsscripts.com
>
> View the list's information and change your settings at
> http://www.freelists.org/list/jawsscripts
>
__________ 
Visit and contribute to The JAWS Script Repository http://jawsscripts.com

View the list's information and change your settings at 
http://www.freelists.org/list/jawsscripts

Other related posts: