I have been quite busy for a little while, but this post is just to remind you that I am still looking for good suggestions and some good Visual Studio C++ 6.0 programmers. I have not forgotten this project.
I am not a MFC Visual C++ person so I may be wrong on this but I see an issue with Visual C++ 6 and the rich edit control you are planning on using.
I do not believe the rich edit control handles unicode characters at least not the control from VC++ 6 which is from around Windows 98 time frame.
Since like I said I am not an MFC person it could very well now be happy with unicode chars.
May I suggest a simple test before you invest a lot of time thinking that is the editor control of choice.
Write a simple test app with the edit control and a file open menu, set the font of the editor to the Parallax Font and see if you see the Parallax drawing characters when you open inductor.spin from the Parallax Lib.
Also another heads up while the compiler will take unicode files or nonunicode files it will be unhappy with a file with embedded formatting control characters that an
editor like rich edit puts in the file because it is designed to make a word processor not a code editor.
As I said in previous post I am a Delphi person so you know MFC so I offer this as a watch out.
I would bet the dot net C# and VB using the dot net lib handle unicode , The rich edit control there would still have issues with control codes.
The only hangup is that we're using a licensed edit control from the Dream Company (now acquired by Altium). We've made contact with the right people at Altium and discussed the exact software license, but nary a soul in the whole company knows the history of this particular software component. We only need to obtain a signature from an Altium representative and then we'll post the Propeller Tool source. I expect this to happen no later than the end of January.
Hello - I have an update on this point above. We were unable to obtain the approval to open-source this licensed component from Altium. We are discussing our options internally at this stage and I'll be back with a solution.
@Ken
My thoughts, take it as throwing out some comments for brainstroming the concept.
I do not think losing the Dream Memo as open source is a big deal in regards to creating a better
prop tool on multiple platforms as it is tied to the windows platform to much. For a Delphi person like myself it would have been nice as it has all the Parallax mods in it. On the other hand maybe I do not even want those as I would prefer to use a different editor.
To me each person wanting to write a proptool on their favorite system ie those mentioned in other threads Windows, Eclipps, a visual studio interface, Qt, Linux will have there own set of components and
tools that they want to use.
To me the project is to define the interface to the compiler that all can use. It is a project to define what should be in the interface and what form the interface takes . If a dynamic link library(dll) is one I would write with Delphi ok for someone using Linux or Visual Studio. Also is one written with Visual Studio which likes dot net usable by anyone else.
I read where releasing the C++ source for everyone to use is the planned idea and I wonder if you really wnat to do that. Think of all the Propeller Tools that would now be out there where people who thought they knew better and modified the compiler code and it now produces the wrong code for which Parallax tech support is getting blamed and called.
I really think you need to keep control of the compiler and define an interface to it that all can use.
Maybe open source C++ code that interfaces to the compiler .
Maybe Parallax will have to supply various dll's for different systems and have an expert local or remote to maintain the one they are expert in, while Parallax maintains the compiler and it's integerity.
Just some thoughts
Tom
I am not real knowledgeable on open source but to me would a company want to bet the company on something written using software everyone has there hands in.
Yep, happens all the time.
Think of all those web sites running on the Linux operating system with Apache web server using Python, PHP, Perl or whatever scripting language and MySql database. All open source.
Think of all those internet routers running out there all based on Linux. Or the Tivo video recorder system. All open source.
Think of all the open source dev tools that are available. The Eclipse IDE for example is the basis of the tool chain form many systems now.
Here's a biggie, think of all those hundreds of millions of Android based phones. Android sits on top of Linux and in fact the entire Android software stack is open source. That's a big bet on open source form Google, Samsung, Sonny-Ericsson, HTC and others.
Since about 1999 all the embedded systems I have worked on, including micro-wave base station control software for Nokia and Urban Traffic Controllers, have been Linux based and used a lot of the typical open source software that sits on top. Not to mention using the open source GCC C/C++ compiler or Free Pascal and all kinds of other open source development tools, libraries and languages.
Could you imagine Toyota saying Senator we do not know who made those mods to the Open Source Lib we used for the accellerator code.
Well for any software vendor making sure his delivered system works to some standard is his responsibility. If the code he uses is developed in house or acquired from commercial third parties or fetched from an open source repository makes no difference.
Actually the motivation for open source is all ready expressed in some of your comments re: proprietary closed source components. Can't find the quotes just now but your statements mentioned:
1) With closed source components everything is fine as long as your vendor is still around and the part is supported. If not the component dies and perhaps your product with it when you find it does no longer works on a new OS version or new platform etc. This is the problem that Parallax has with their edit control, they want to move on but have to jettison that boat anchor first.
2) With closed source components you have sometimes been convince that the part was buggy, perhaps looking like it had never been tested sufficiently, and perhaps requiring repair by the user.
So we see that open source alleviates those problems by being available indefinitely and being fixable by anyone who has a stake.
Having had a lot of my code and code of the companies I've worked become unusable due to the death of an operating system or tool chain, library vendor, whatever, I would rather bet my business on open source.
Think of all the Propeller Tools that would now be out there where people who thought they knew better and modified the compiler code and it now produces the wrong code for which Parallax tech support is getting blamed and called. I really think you need to keep control of the compiler and define an interface to it that all can use.
For all the reasons state above, and more, no.
Yes I think that is a valid concern, having a dozen different dialects of Spin out there would be a pain for everyone. However that has already happened even with the Prop Tool being closed source. For a time there was:
1) The Parallax Prop Tool
2) BradC's wondeful BST compiler.
3) Mparks HomeSpun.
They were all different dialects of Spin. Code could not be guaranteed to be movable form one to another unchanged.
BST and HomeSpun have converged recently but I'm not sure it's 100% the same.
The issue is control of the language not control of the compiler. After all languages like C/C++ get by just fine even with dozens of compiler vendors, open source or not.
Consider: If someone takes the parallax compiler code and adds some nifty features that everyone is clamoring for then it becomes much easier for Parallax to absorb those improvements into their "official" compiler releases.
Consider: If someone takes the parallax compiler code and adds some nifty features that everyone is clamoring for then it becomes much easier for Parallax to absorb those improvements into their "official" compiler releases.
I believe this open source editor component is mentioned in one of the other new PropTool discussions
Scintilla http://www.scintilla.org/ may be a replacement for trying to Open Source the Dream Memo for a new PropTool. It is used in Notepad++ .
Looks to be C++ but there is even a Delphi wrapper of some kind.
I don't see what's wrong with the current IDE. It has text highlighting, block coloring, and a find/replace feature. Of course, the only other IDE I've ever used has been the Basic Stamp one, so I don't know any "professional" tools, but I think it's fine the way it is. The only thing I would like added is autocomplete for code and routine names, but even this I may find annoying. I've used the Visual Basic IDE and I don't like having the excessive toolset. It's confusing and I like simplicity. So if a new Propeller Tool would be like that, I'd like to just use the current one.
I would love the Propeller tool in an Android App. USB from my tablet to the propeller would be amazing! I like to work with the propeller while I'm on the road, but don't want to lug around my notebook and assorted accessories.
I would love the Propeller tool in an Android App. USB from my tablet to the propeller would be amazing! I like to work with the propeller while I'm on the road, but don't want to lug around my notebook and assorted accessories.
I'd like that, too, especially as I carry my new Kindle Fire everywhere I go (weighs less that books). The problem, vis-a-vis this thread, is that the proponent is going down the Windows-only path. IMHO, Parallax's insistence on making the Propeller Tool Windows-only has cost them dearly. When the Propeller was released there was no such thing as the Arduino and now, in six years, it's eating everyone's lunch. Why? Because its editor, bad as it is, runs on all the major OS platforms. To have a discussion about a "better" tool without consideration of going multi-platform seems short-sighted, or at least ignoring the recent past.
I'd like that, too, especially as I carry my new Kindle Fire everywhere I go (weighs less that books). The problem, vis-a-vis this thread, is that the proponent is going down the Windows-only path. IMHO, Parallax's insistence on making the Propeller Tool Windows-only has cost them dearly. When the Propeller was released there was no such thing as the Arduino and now, in six years, it's eating everyone's lunch. Why? Because its editor, bad as it is, runs on all the major OS platforms. To have a discussion about a "better" tool without consideration of going multi-platform seems short-sighted, or at least ignoring the recent past.
I hear the call for defense!
Parallax is progressing on the C/C++ compiler conversion from assembly. We expect to have this completed by the end of this month. With it, there shall be far fewer barriers to produce multi-OS programming tools.
Also, you conveniently neglected to point out the efforts we've made with PropGCC. It's already running on Mac, Linux and Windows.
What you're seeing is where we've been, not where we're going. There shall be no more Windows-only efforts at Parallax in our future, JonnyMac!
I have not had a chance to thoroughly look at this, because I am currently preoccupied, but from the pics, this open source edit control looks pretty nice.
That control is based on MFC, so would be difficult to integrate to a Delphi/Lazaraus-based IDE (which I've heard PropTool is). Scintilla is a popular open source edit control, and since it was originally created for a Python IDE, I know it has good support for indent-based languages.
It's already been done. The Scintilla edit control is used in the opensource crossplatform Propeller IDE PZST (Propeller Zone Spin Tool) by Andre Demenev.
Ken, are you saying that by the end of the year there will be an opensource Spin/PASM compiler available that we can adopt for such tools as PZST?
It's already been done. The Scintilla edit control is used in the opensource crossplatform Propeller IDE PZST (Propeller Zone Spin Tool) by Andre Demenev.
Ken, are you saying that by the end of the year there will be an opensource Spin/PASM compiler available that we can adopt for such tools as PZST?
Hello heater, this is the schedule I've been given by the developer. I am working closely with him to see that it's actually accomplished. Some testing will be required and we will likely bring the community in to assist us.
Parallax is progressing on the C/C++ compiler conversion from assembly. We expect to have this completed by the end of this month. With it, there shall be far fewer barriers to produce multi-OS programming tools.
Also, you conveniently neglected to point out the efforts we've made with PropGCC. It's already running on Mac, Linux and Windows.
What you're seeing is where we've been, not where we're going. There shall be no more Windows-only efforts at Parallax in our future, JonnyMac!
When the Propeller was released there was no such thing as the Arduino and now...
Not wanting to jump into the firestorm itself, I just wanted to point out the Arduino predates the Propeller by a good year (or maybe that's by a Michelin; I never could get my tires straight).
The Arduino's cross-OS is at the hands of Java, though. There are some companies out there that forbid Java from being installed on their computers, so it's not the panacea it's made out to be. Strangely enough, Flash is allowed on more PCs in the world than Java. That's what we need - an IDE based on Flash!!
When I started this thread, it was out of the intention to create a better Propeller Tool for myself, and hopefully others would have benefited by it. But like many of my other projects, other items have taken precedence. That being said, the WINDOWS only approach from my standpoint was due to the fact of my limited knowledge. WINDOWS is the only OS that I have ever used, so I write my programs for a WINDOWS environment. But yes, that is a severe limitation to software, especially for a company like Parallax and their products.
As I try to build my business, I become more aware of the fact that every task requires a certain amount of dedicated time, and there is always a limited amount of resources that can be applied to a given task.
I am certain that the original Propeller Tool was just a piece of software meant to get the ball rolling for the Propeller chip. Let's call it a quick fix. Even though I do not participate in the forum as I once did, I still read the articles from time to time, and from what I have read, Parallax is now devoting some serious time and resources to put out some nice software.
I am certain that these endeavors for new software will help to push the Propeller and Parallax into a much higher class. It all takes time. Keep up the good work Parallax.
What you're seeing is where we've been, not where we're going. There shall be no more Windows-only efforts at Parallax in our future, JonnyMac!
Excellent news. My point was that making a "better Propeller Tool" for Windows users only neglects a whole lot of potential customers. And you know how those Linux folks can get!
...the Arduino predates the Propeller by a good year...
Let me restate, then; it certainly didn't have the presence it has now. Over the summer was asked on three separate occasions, "Is that some kind of Arduino board?" Twice I was using my Propeller Platform, the third time I was using a QuickStart. Sadly, Arduino seems to be the first microcontroller on the public's mind... kind of like the BASIC Stamp used to be. In my opinion, the Arduino's cross-platform tool made it more available hence it was able to gain market traction.
Mind you, I have no skin in this anymore. That said, I have friends at Parallax and I'd like to see them thrive.
Well, now that everyone has put in their excellent suggestions, let me throw a wrench into the works.
1.
let me start by saying I realize there are very few programmers that are blind, though I know there's several thousand out there in varying capacities), (I know less than a hundred myself.
2. The number of these guys (and gals to be fair) that would even attempt programming on micro controllers like the propeller and basic stamp are definitely far fewer, I would like to put in my request now (so it doesn't get lost) that any tools that be produced at least make an attempt to be accessible to screen readers.
I realize this entails a lot of headscratching for the average developer, because they have no idea what accessible means, but to give an example.
The basic stamp editor is 100 percentt accessible, I have no problem editing my programs using it, downloading programs to the stamp, and even the debug terminal works very well.
On the other hand, the propeller tool is horrible when it comes to accessibility issues. The code is mixed up with everything else on the screen, and won't even read out when moving from line to line like the basic stamp software does, arrowing up/down in the stamp editor not only tells me what line I'm on, but also reads out the line in question, so I know exactly what's going on.
The propeller tool does not do this, and though most screen reading software gives the ability to limit areas of the screen to be watched, for things like editing, I've given up trying to edit my code for the propeller using the prop tool. I simply use a stand-alone text editor, then when I'm ready to test the code I load it into the propeller editor, and do the rest from there.
The fact that keystrokes exist to perform downloads, code checks and the like, is excellent, as this allows keyboarding instead of icon hunting, but apparently the editing control used for the code itself isn't a standard windows control, so it doesn't act as expected by screen reader users.
Of course, an opensource version of the code can easily be tweaked to behave properly once it's released, so these issues are somewhat mitigated by this fact. However, I'd strongly urge programmers of any tools to try to use windows provided controls whenever possible, as this will (usually) automatically make th code work for screen readers. The osx version of the propeller tool (bst) works well, because all of the controls are standard apple controls, and voiceover (the screen reader built into osx) works well as a result).
3. Also, any tool should really at least attempt to be cross-platform, since a growing number of folks are finding windows alternatives, and anything tied directly to windows won't win any friends in those circles. I realize windows is still the largest segment, but eliminating the others out of the gate doesn't help garner support in the very circles the products are trying to attract. I'd wager one reason the arduino is so popular, is not only because of it's open design, but also because they support platforms other than windows, and most folks don't even realize Parallax has non-windows editors.
Of course, again, opensource will help here too. I know bst for osx has been asking for some time to get an intel version of the library used to tokenize the code, so it can be ported to intel-based macs, which is mandatory for lion and beyond, as those versions of osx no longer run on ppc macs, and won't work in the roseta emulator since it's been removed (snowleopard was the last one to have that).
So, right out of the box, having accessibility built-in, supporting multiple platforms, and providing programming books both in electronic and hard copy versions are the ways to gain as much market share as possible.
Sorry, I certainly didn't mean for this to turn into a rant. I'm only trying to ensure I (and any others who wish to join me in the blind/visually impaired arena of micron controller development) have a relatively painless time of it.
* How about some kind of intelligent spelling checker that sees what you're trying to do and suggests a list of known register names, opcodes and constants and whatnot.
* Something that warns of common mistakes like using "test ina, #1" when it should really be "test #1, ina". Another one would be getting your "res" and "long" declarations in the wrong order.
The simple things can improve a product immensely.
Actually, a quick win for providing features that @softcon mentioned might be...
* the ability to either nominate an external text editor to do the code modification (an editor that IS screen reader compatible) or perhaps just to compile and upload a spin file without forcing the user to open it first. All they'd have to do is nominate the file once, and then just hit F11 any time they want it compiled and uploaded, any errors can be spat out as plaintext into the designated editor as a new text file.
That would at least get the visually impaired user to where they want to be and would be minimal development for the Propeller team.
That's exactly what I do now with the propeller, with the exception that I don't call the editor directly when it's time for download of code, though now that you mention it, I coulld probably automate that too) There's several editors that interface with command line compiler tools to get the job done, so something like that for the new parallax editors would be great, just give us command-line options to download code (with filename passed on command-line) or to perform a syntax check on file mentioned on command-line, and all will be well (and if stdio is used for error messages, then the screen readers will work just fine) hth.Command line parameter passing will allow scripts to automate compiles too.
Comments
I have been quite busy for a little while, but this post is just to remind you that I am still looking for good suggestions and some good Visual Studio C++ 6.0 programmers. I have not forgotten this project.
Bruce
I do not believe the rich edit control handles unicode characters at least not the control from VC++ 6 which is from around Windows 98 time frame.
Since like I said I am not an MFC person it could very well now be happy with unicode chars.
May I suggest a simple test before you invest a lot of time thinking that is the editor control of choice.
Write a simple test app with the edit control and a file open menu, set the font of the editor to the Parallax Font and see if you see the Parallax drawing characters when you open inductor.spin from the Parallax Lib.
Also another heads up while the compiler will take unicode files or nonunicode files it will be unhappy with a file with embedded formatting control characters that an
editor like rich edit puts in the file because it is designed to make a word processor not a code editor.
As I said in previous post I am a Delphi person so you know MFC so I offer this as a watch out.
I would bet the dot net C# and VB using the dot net lib handle unicode , The rich edit control there would still have issues with control codes.
Tom
It needs the capabilities of ViewPort built in.
It needs a more powerful assembler for PASM.
It needs the C and BASIC compilers integrated into it.
Code generators would be nice for PASM at least...
for all the languages would be even sweeter.
More helpful hand holding tutorials for newbies in PASM and spin!
Hello - I have an update on this point above. We were unable to obtain the approval to open-source this licensed component from Altium. We are discussing our options internally at this stage and I'll be back with a solution.
Thanks for your patience.
Ken Gracey
My thoughts, take it as throwing out some comments for brainstroming the concept.
I do not think losing the Dream Memo as open source is a big deal in regards to creating a better
prop tool on multiple platforms as it is tied to the windows platform to much. For a Delphi person like myself it would have been nice as it has all the Parallax mods in it. On the other hand maybe I do not even want those as I would prefer to use a different editor.
To me each person wanting to write a proptool on their favorite system ie those mentioned in other threads Windows, Eclipps, a visual studio interface, Qt, Linux will have there own set of components and
tools that they want to use.
To me the project is to define the interface to the compiler that all can use. It is a project to define what should be in the interface and what form the interface takes . If a dynamic link library(dll) is one I would write with Delphi ok for someone using Linux or Visual Studio. Also is one written with Visual Studio which likes dot net usable by anyone else.
I read where releasing the C++ source for everyone to use is the planned idea and I wonder if you really wnat to do that. Think of all the Propeller Tools that would now be out there where people who thought they knew better and modified the compiler code and it now produces the wrong code for which Parallax tech support is getting blamed and called.
I really think you need to keep control of the compiler and define an interface to it that all can use.
Maybe open source C++ code that interfaces to the compiler .
Maybe Parallax will have to supply various dll's for different systems and have an expert local or remote to maintain the one they are expert in, while Parallax maintains the compiler and it's integerity.
Just some thoughts
Tom
Yep, happens all the time.
Think of all those web sites running on the Linux operating system with Apache web server using Python, PHP, Perl or whatever scripting language and MySql database. All open source.
Think of all those internet routers running out there all based on Linux. Or the Tivo video recorder system. All open source.
Think of all the open source dev tools that are available. The Eclipse IDE for example is the basis of the tool chain form many systems now.
Here's a biggie, think of all those hundreds of millions of Android based phones. Android sits on top of Linux and in fact the entire Android software stack is open source. That's a big bet on open source form Google, Samsung, Sonny-Ericsson, HTC and others.
Since about 1999 all the embedded systems I have worked on, including micro-wave base station control software for Nokia and Urban Traffic Controllers, have been Linux based and used a lot of the typical open source software that sits on top. Not to mention using the open source GCC C/C++ compiler or Free Pascal and all kinds of other open source development tools, libraries and languages.
Well for any software vendor making sure his delivered system works to some standard is his responsibility. If the code he uses is developed in house or acquired from commercial third parties or fetched from an open source repository makes no difference.
Actually the motivation for open source is all ready expressed in some of your comments re: proprietary closed source components. Can't find the quotes just now but your statements mentioned:
1) With closed source components everything is fine as long as your vendor is still around and the part is supported. If not the component dies and perhaps your product with it when you find it does no longer works on a new OS version or new platform etc. This is the problem that Parallax has with their edit control, they want to move on but have to jettison that boat anchor first.
2) With closed source components you have sometimes been convince that the part was buggy, perhaps looking like it had never been tested sufficiently, and perhaps requiring repair by the user.
So we see that open source alleviates those problems by being available indefinitely and being fixable by anyone who has a stake.
Having had a lot of my code and code of the companies I've worked become unusable due to the death of an operating system or tool chain, library vendor, whatever, I would rather bet my business on open source.
For all the reasons state above, and more, no.
Yes I think that is a valid concern, having a dozen different dialects of Spin out there would be a pain for everyone. However that has already happened even with the Prop Tool being closed source. For a time there was:
1) The Parallax Prop Tool
2) BradC's wondeful BST compiler.
3) Mparks HomeSpun.
They were all different dialects of Spin. Code could not be guaranteed to be movable form one to another unchanged.
BST and HomeSpun have converged recently but I'm not sure it's 100% the same.
The issue is control of the language not control of the compiler. After all languages like C/C++ get by just fine even with dozens of compiler vendors, open source or not.
Consider: If someone takes the parallax compiler code and adds some nifty features that everyone is clamoring for then it becomes much easier for Parallax to absorb those improvements into their "official" compiler releases.
Sorry for such a long post every one:)
A very good point.
1) Dot Notation + Autocomplete
2) Global variables
thanks
Scintilla http://www.scintilla.org/ may be a replacement for trying to Open Source the Dream Memo for a new PropTool. It is used in Notepad++ .
Looks to be C++ but there is even a Delphi wrapper of some kind.
Tom
I'd like that, too, especially as I carry my new Kindle Fire everywhere I go (weighs less that books). The problem, vis-a-vis this thread, is that the proponent is going down the Windows-only path. IMHO, Parallax's insistence on making the Propeller Tool Windows-only has cost them dearly. When the Propeller was released there was no such thing as the Arduino and now, in six years, it's eating everyone's lunch. Why? Because its editor, bad as it is, runs on all the major OS platforms. To have a discussion about a "better" tool without consideration of going multi-platform seems short-sighted, or at least ignoring the recent past.
I hear the call for defense!
Parallax is progressing on the C/C++ compiler conversion from assembly. We expect to have this completed by the end of this month. With it, there shall be far fewer barriers to produce multi-OS programming tools.
Also, you conveniently neglected to point out the efforts we've made with PropGCC. It's already running on Mac, Linux and Windows.
What you're seeing is where we've been, not where we're going. There shall be no more Windows-only efforts at Parallax in our future, JonnyMac!
Ken Gracey
That control is based on MFC, so would be difficult to integrate to a Delphi/Lazaraus-based IDE (which I've heard PropTool is). Scintilla is a popular open source edit control, and since it was originally created for a Python IDE, I know it has good support for indent-based languages.
Ken, are you saying that by the end of the year there will be an opensource Spin/PASM compiler available that we can adopt for such tools as PZST?
Hello heater, this is the schedule I've been given by the developer. I am working closely with him to see that it's actually accomplished. Some testing will be required and we will likely bring the community in to assist us.
Ken Gracey
Great news about the windows only support!
-Phil
Not wanting to jump into the firestorm itself, I just wanted to point out the Arduino predates the Propeller by a good year (or maybe that's by a Michelin; I never could get my tires straight).
The Arduino's cross-OS is at the hands of Java, though. There are some companies out there that forbid Java from being installed on their computers, so it's not the panacea it's made out to be. Strangely enough, Flash is allowed on more PCs in the world than Java. That's what we need - an IDE based on Flash!!
-- Gordon
When I started this thread, it was out of the intention to create a better Propeller Tool for myself, and hopefully others would have benefited by it. But like many of my other projects, other items have taken precedence. That being said, the WINDOWS only approach from my standpoint was due to the fact of my limited knowledge. WINDOWS is the only OS that I have ever used, so I write my programs for a WINDOWS environment. But yes, that is a severe limitation to software, especially for a company like Parallax and their products.
As I try to build my business, I become more aware of the fact that every task requires a certain amount of dedicated time, and there is always a limited amount of resources that can be applied to a given task.
I am certain that the original Propeller Tool was just a piece of software meant to get the ball rolling for the Propeller chip. Let's call it a quick fix. Even though I do not participate in the forum as I once did, I still read the articles from time to time, and from what I have read, Parallax is now devoting some serious time and resources to put out some nice software.
I am certain that these endeavors for new software will help to push the Propeller and Parallax into a much higher class. It all takes time. Keep up the good work Parallax.
Bruce
Excellent news. My point was that making a "better Propeller Tool" for Windows users only neglects a whole lot of potential customers. And you know how those Linux folks can get!
Let me restate, then; it certainly didn't have the presence it has now. Over the summer was asked on three separate occasions, "Is that some kind of Arduino board?" Twice I was using my Propeller Platform, the third time I was using a QuickStart. Sadly, Arduino seems to be the first microcontroller on the public's mind... kind of like the BASIC Stamp used to be. In my opinion, the Arduino's cross-platform tool made it more available hence it was able to gain market traction.
Mind you, I have no skin in this anymore. That said, I have friends at Parallax and I'd like to see them thrive.
1.
let me start by saying I realize there are very few programmers that are blind, though I know there's several thousand out there in varying capacities), (I know less than a hundred myself.
2. The number of these guys (and gals to be fair) that would even attempt programming on micro controllers like the propeller and basic stamp are definitely far fewer, I would like to put in my request now (so it doesn't get lost) that any tools that be produced at least make an attempt to be accessible to screen readers.
I realize this entails a lot of headscratching for the average developer, because they have no idea what accessible means, but to give an example.
The basic stamp editor is 100 percentt accessible, I have no problem editing my programs using it, downloading programs to the stamp, and even the debug terminal works very well.
On the other hand, the propeller tool is horrible when it comes to accessibility issues. The code is mixed up with everything else on the screen, and won't even read out when moving from line to line like the basic stamp software does, arrowing up/down in the stamp editor not only tells me what line I'm on, but also reads out the line in question, so I know exactly what's going on.
The propeller tool does not do this, and though most screen reading software gives the ability to limit areas of the screen to be watched, for things like editing, I've given up trying to edit my code for the propeller using the prop tool. I simply use a stand-alone text editor, then when I'm ready to test the code I load it into the propeller editor, and do the rest from there.
The fact that keystrokes exist to perform downloads, code checks and the like, is excellent, as this allows keyboarding instead of icon hunting, but apparently the editing control used for the code itself isn't a standard windows control, so it doesn't act as expected by screen reader users.
Of course, an opensource version of the code can easily be tweaked to behave properly once it's released, so these issues are somewhat mitigated by this fact. However, I'd strongly urge programmers of any tools to try to use windows provided controls whenever possible, as this will (usually) automatically make th code work for screen readers. The osx version of the propeller tool (bst) works well, because all of the controls are standard apple controls, and voiceover (the screen reader built into osx) works well as a result).
3. Also, any tool should really at least attempt to be cross-platform, since a growing number of folks are finding windows alternatives, and anything tied directly to windows won't win any friends in those circles. I realize windows is still the largest segment, but eliminating the others out of the gate doesn't help garner support in the very circles the products are trying to attract. I'd wager one reason the arduino is so popular, is not only because of it's open design, but also because they support platforms other than windows, and most folks don't even realize Parallax has non-windows editors.
Of course, again, opensource will help here too. I know bst for osx has been asking for some time to get an intel version of the library used to tokenize the code, so it can be ported to intel-based macs, which is mandatory for lion and beyond, as those versions of osx no longer run on ppc macs, and won't work in the roseta emulator since it's been removed (snowleopard was the last one to have that).
So, right out of the box, having accessibility built-in, supporting multiple platforms, and providing programming books both in electronic and hard copy versions are the ways to gain as much market share as possible.
Sorry, I certainly didn't mean for this to turn into a rant. I'm only trying to ensure I (and any others who wish to join me in the blind/visually impaired arena of micron controller development) have a relatively painless time of it.
and watch the code execute.
* Something that warns of common mistakes like using "test ina, #1" when it should really be "test #1, ina". Another one would be getting your "res" and "long" declarations in the wrong order.
The simple things can improve a product immensely.
* the ability to either nominate an external text editor to do the code modification (an editor that IS screen reader compatible) or perhaps just to compile and upload a spin file without forcing the user to open it first. All they'd have to do is nominate the file once, and then just hit F11 any time they want it compiled and uploaded, any errors can be spat out as plaintext into the designated editor as a new text file.
That would at least get the visually impaired user to where they want to be and would be minimal development for the Propeller team.