PropellerIDE User Experience
PerryCodes
Posts: 2
I'll take another stab at this, with a tone that's more appropriate for the situation - as alluded to by David.
--
Yesterday, I spent about an hour getting PropellerIDE working under OSX (10.10.5) and another hour or so familiarizing myself with the software. I have quite a bit of experience with the Propeller Tool under Windows and both BST and SimpleIDE on Mac. The prospect of a single tool that functions equivalently under Linux, Mac, and Windows is attractive, so I wanted to know how PropellerIDE stacked up to existing tools. The following chronicles my initial thoughts re: the OSX version of PropellerIDE, numbered to facilitate replies to specific items.
1) The very first thing I noticed was the UI resembles SimpleIDE to a certain degree. I haven't looked through the source code yet and I haven't been on Mac for very long, so I don't know if the resemblance has anything to do with the code or more to do with UI patterns.
2) One big difference with the SimpleIDE UI had to do with Font Rendering. Regardless of the font I use, SimpleIDE font rendering looks terrible. It might be forcing anti-aliasing... I don't know... but the fonts just don't line up on pixel boundaries. That problem does not exist in PropellerIDE. I demoed several "programming" fonts and they all looked great.
3) Then came time to test a simple HelloWorld.spin project. I had to change the port for my QuickStart board from the first one in the list to the correct one. Then I tried to do a simple compile without doing a load. That's when I was treated to the following error:
Could not start "."
Since that error offered no clue as to what the problem may be, I took to Google. The one post I found where another user was getting that same error pointed to a missing OpenSpin as potentially the problem. Though that didn't seem to be my problem, it did get me poking around the right area. The first tab in Preferences point to the location of the Compiler and the Include dir(s). On OSX, both locations were under PropellerIDE.app and although the Compiler path was correct, the Include location did not point to a valid folder.
After fixing this bug, the project could both compile and load the binary correctly.
4) The next problem I noticed has to do with USB port selection. Although IDE-179 is marked as "Done", my experience says otherwise. My QuickStart board is the second item in the listbox and after I close/re-open the app, selected always returns to the first item (a bluetooth device, that's not currently connected). That might seem like a minor issue, except that the same problem occurs for the Console port selection... So each time I try and launch an app that uses the console, there is a one minute delay while the app tries to connect to a bluetooth board on the incorrect port. The app should be able to save/recall the last connected device correctly (in both the main ui AND the cosole).
5) Finally - and what I would consider my biggest problem with an app that's been in development for 1.5 years - the active document allows itself to be closed after changes have been made... without prompting the user to ask if the changes should be saved. They are simply discarded. Without reverting back to the tone in v1 of this post, I consider this a major bug. One that should never exist.
I will close with a book recommendation that any software developer serious about their trade should have, should read, and should use: About Face. They are on the fourth edition of this book, which means you can get the previous editions for less than a dollar on Amazon. Well worth it, especially considering that developers can no longer get away with neglecting the User Experience aspect of Software Development... or in many cases putting if off until late in the schedule or labeling it "minor" in the issue tracker.
Regards ~ Jason
--
Yesterday, I spent about an hour getting PropellerIDE working under OSX (10.10.5) and another hour or so familiarizing myself with the software. I have quite a bit of experience with the Propeller Tool under Windows and both BST and SimpleIDE on Mac. The prospect of a single tool that functions equivalently under Linux, Mac, and Windows is attractive, so I wanted to know how PropellerIDE stacked up to existing tools. The following chronicles my initial thoughts re: the OSX version of PropellerIDE, numbered to facilitate replies to specific items.
1) The very first thing I noticed was the UI resembles SimpleIDE to a certain degree. I haven't looked through the source code yet and I haven't been on Mac for very long, so I don't know if the resemblance has anything to do with the code or more to do with UI patterns.
2) One big difference with the SimpleIDE UI had to do with Font Rendering. Regardless of the font I use, SimpleIDE font rendering looks terrible. It might be forcing anti-aliasing... I don't know... but the fonts just don't line up on pixel boundaries. That problem does not exist in PropellerIDE. I demoed several "programming" fonts and they all looked great.
3) Then came time to test a simple HelloWorld.spin project. I had to change the port for my QuickStart board from the first one in the list to the correct one. Then I tried to do a simple compile without doing a load. That's when I was treated to the following error:
Could not start "."
Since that error offered no clue as to what the problem may be, I took to Google. The one post I found where another user was getting that same error pointed to a missing OpenSpin as potentially the problem. Though that didn't seem to be my problem, it did get me poking around the right area. The first tab in Preferences point to the location of the Compiler and the Include dir(s). On OSX, both locations were under PropellerIDE.app and although the Compiler path was correct, the Include location did not point to a valid folder.
After fixing this bug, the project could both compile and load the binary correctly.
4) The next problem I noticed has to do with USB port selection. Although IDE-179 is marked as "Done", my experience says otherwise. My QuickStart board is the second item in the listbox and after I close/re-open the app, selected always returns to the first item (a bluetooth device, that's not currently connected). That might seem like a minor issue, except that the same problem occurs for the Console port selection... So each time I try and launch an app that uses the console, there is a one minute delay while the app tries to connect to a bluetooth board on the incorrect port. The app should be able to save/recall the last connected device correctly (in both the main ui AND the cosole).
5) Finally - and what I would consider my biggest problem with an app that's been in development for 1.5 years - the active document allows itself to be closed after changes have been made... without prompting the user to ask if the changes should be saved. They are simply discarded. Without reverting back to the tone in v1 of this post, I consider this a major bug. One that should never exist.
I will close with a book recommendation that any software developer serious about their trade should have, should read, and should use: About Face. They are on the fourth edition of this book, which means you can get the previous editions for less than a dollar on Amazon. Well worth it, especially considering that developers can no longer get away with neglecting the User Experience aspect of Software Development... or in many cases putting if off until late in the schedule or labeling it "minor" in the issue tracker.
Regards ~ Jason
Comments
Jason
Thanks David, it's nice to know people have my back when I'm away from the forums.
Now, to get down to business.
You're absolutely right. Before I took over the project, PropellerIDE began its life as a fork of an early version of SimpleIDE, and still resembles it to some degree on the surface. However, in the year and a half since I took it over, it could not be more different under the hood. Today, PropellerIDE includes several different projects.
- PropellerManager, a Propeller loader framework
- Spin Standard Library, a collection of core libraries bundled with PropellerIDE, based on the original PropTool collection
- projectparser, a generic project hierarchy builder and viewer widget
- memorymap, a QHexEdit-based memory map widget
- propterm, a PropellerManager-enabled terminal widget
- packthing, a multi-source packaging tool that automates deployment on various platforms
None of these existed before I took over the project, but even in the core editor itself, I have hacked away at its internals to the point that it looks almost nothing like it did on the inside, removing thousands of lines of code and adding thousands more. This is to support many long-term goals I have for the IDE.
- PropellerIDE should be stable and easy to maintain.
- PropellerIDE should have a plugin interface for adding new functionality.
- PropellerIDE should run on all available platforms, including desktop and mobile.
- PropellerIDE should include a comprehensive set of debugging tools: terminal, memory map, heat map, oscilloscope, logic analyzer, and more.
- PropellerIDE should support all languages available for the Propeller microcontroller.
I have done a great deal towards this end, but there is still a lot to go. Thank you for noticing.
There is a discussion about this issue here:
https://github.com/parallaxinc/PropellerIDE/issues/32
The fix in and of itself is small, but I've been busy trying to develop new curriculum for LameStation so I haven't put out any new releases recently.
Can you reproduce the name of the bluetooth device? I added code to filter bluetooth devices a long time ago, so I'm surprised they're still showing up. I will save your suggestion of attempting to reopen the last used device though.
It's easy to say that bugs should never exist, but that's why they are bugs. That said, the problem is more difficult than it sounds to fix.
I have observed this behavior before. Since there is already code that prevents this from happening in most circumstances, I haven't figured out why exactly it occurs. In any case, I've shelved the problem because file management is already a target for major refactoring. The future FileManager will have the following features:
- RAM buffering of files opened - all parts of the application access the same buffer of a file, through the same interface, and no file can ever be opened more than once. This prevents one part of the application from clobbering another, and is required for split-view editing, safe file saving, and much faster editor performance.
- Tracking filesystem notifiers - PropellerIDE will be able to complain if you modify the file outside the application.
The current IDE already has RAM buffering to a degree, but the implementation needs work, as you've discovered. It's also tied to the tab widget currently, so view splitting is currently impossible. So while I want to fix it, I'll end up having to fix it again once all this is done.
User experience has never been a "minor" consideration of PropellerIDE development. I categorize issues based on the amount of work required to fix them, not how pressing they are at the moment. Every issue is just as important as the last, as they all contribute to a functioning, easy-to-use piece of software.
Case in point: the "Could not start '.'" error is only showing up now after I overlooked something rewriting the Preferences system about a month ago. Why did I do that? Because the user interface was hard-coded and never would have supported another language. Well, now it does, and I am closer than ever before to offering an IDE that can support PropBASIC (seamlessly!) alongside Spin. But I broke something stupid in the process and haven't had a chance to fix it.
Six months ago, there was a similar "Could not start" error for the loader. Now that error doesn't even exist anymore. Why not? Because I wrote a brand new loader framework that can be embedded into the IDE completely. Now PropellerIDE always has a loader ready to go, and what's more, it can play alongside the terminal. You can have as many terminals open as you want, even to the same device, and you can STILL download, without having to disconnect and reconnect and drive yourself crazy. I did that. For user experience. And the first chance I get, I'm going to do the same for the compiler.
I know it's hard to see from the outside, but as much as one person can, I have committed myself to producing the best IDE for the Propeller that I possibly can, with the resources that I have. So if that's not good enough for you, then I challenge you to help me to make it better!
I've seen this same problem just recently (i.e. not sure which version of Propeller IDE it started within)... The Bluetooth device listed in Propeller IDE and terminal on my MacBook Pro is "cu.linvor-DevB", which seems to be non-mounted device, whose driver I had downloaded a while back. It belongs to a Bluetooth device of this type amazon.com/JY-MCU-Arduino-Bluetooth-Wireless-Serial/dp/B009DZQ4MG. Since that device is not mounted via USB-to-serial or is anywhere near my MacBook Pro (I'm in Solvang CA and my home is about 250 miles away, where you might find the device :-), I assume that there's confusion within the driver or Mac OS X about the device's status
After fiddling a bit with selecting a true propeller-based usb device, Propeller IDE seems fine until next launch. But, I think it would help to diagnose this issue. Let me know if there is any info that you need to debug this.
All in all, Propeller IDE provides a very reasonable solution for Spin code development. You've managed to keep this app available on Windows, Mac & Linux variants and I applaud the fact that the UI is quite useable on all of them. I'm sure you will improve the app over time and most of us forum users are very willing to help!
Brett, thanks for all your hard work.
dgately
Thanks,
-Phil
I've never understood this. If a company wants users to use their product then they need to step up the game and pay someone to get it finished. Otherwise it drags on and on for years and just ends up disappointing people and they eventually leave.
-Phil
I noticed we were not considered for our contribution to this project above so I thought I should bring it to the surface. I'm sure that with our support that Propeller IDE improved much more than it would have in the full volunteer model.
Ken Gracey
Not likely. It would take a lot of development to get to that point.
Ken Gracey
I guess I'm perplexed by your answer. What advantage -- technical or marketing -- do you see for having two different IDEs support C? Obviously, Spin and C can't share the same libraries. Why not keep them segregated? 'Just curious ...
Thanks,
-Phil
P.S. I see you edited your comment while I was posting. That tempers my question a bit.
I doubt Ken wants to keep them segregated. Simply, the cost to bring all the SimpleIDE features into Propeller IDE will be quite high. The budget probably doesn't have room for it yet.
One IDE for everything could be beneficial to our customers depending on the user interface design. However, you are aware that SimpleIDE and PropellerIDE come from two different developers, right? Both developers have missions supported by Parallax to achieve different things right now. SimpleIDE will be released with new Learn libraries and WiFi support at some point; PropellerIDE would be improved to address the issues listed in the GitHub repo (and in comments above).
The benefits to Parallax of combining C and Spin support into one tool are that we'd not have so many tools, developers and operating systems to support. Our customers could download one tool and choose their language. The costs of doing this would be significant. Parallax would need to allocate resources (people, financial) to achieve this goal, of course.
Basically it's what David said above.
Would it be better to have one tool? Yes, I think so - if the user experience could make both languages exist with proper support. The plan for the Parallax IDE (Chrome Tool) has been to eventually make it capable of supporting all languages within the Chrome browser, but we are still working on BASIC Stamp issues.
We have no plans right now to support a combined tool effort between SimpleIDE and PropellerIDE.
It's suppose all a matter of resource availability, probably not technical issues. It seems that Qt has proven to be a useful code base for many Parallax software products.
Ken Gracey
I would imagine that you do have statistics on language and IDE usage. If so, what do they look like?
msrobots and I demonstrated that it was quite easy to compile Spin programs in a browser. Just transpile the Open Source Spin compiler to Javascript with Emscripten and run it as a web worker in the browser. See my initial experimental Spin editor/compiler here: http://propanel.oo.fi/lab/spine.html and msrobot's full featured Spin IDE herehttp://propanel.oo.fi/lab/editor17/editor17.html (Sorry, none of the file uplaod/down load works on my installation but it will compile code you enter there). Both with Spin syntax highlighting courtesy of msrobots.
Given the huge size and complexity of prop-gcc I don't see that ever working in the browser, I'm not sure it makes any sense to do that.
Or are you aiming to have the editor in the browser and the compiler on a remote server? Or perhaps a server on the users local machine, say written in node.js?
I've always thought the the idea behind SimpleIDE was to be, well, simple. Like the Arduino IDE for C++. It seemed to grow in complexity all the time though.
Then I thought the idea behind PropellerIDE was to be simple. Dedicated to Spin. Do one job and do it well. In the Spirit of the Parallax Propeller Tool and BradC's BST. Looks like Propeller IDE is now going to get bogged down in complexity.
What is the motivation for anyone to work on SimpleIDE or PropellerIDE if the end goal is to do it all in a Chrome app?
This is all very confusing.
Thanks for asking for clarification.
I should've said that we "had planned" on certain additions to ParallaxIDE but those are currently on hold. With the BASIC Stamp being the most important tool to support due to middle school usage of the Boe-Bot (and mass deployment of Chromebooks) it was our top priority. We are still working on the user interface details for the BASIC Stamp. When this is done we will be stopping on ParallaxIDE for a while.
Next, we had planned to support Spin for two reasons: it's possible, as you stated above and would be useful to a number of customers. The vision for C was likely using remote compilation on a server. However, these two efforts are currently not scheduled.
Motivation for somebody to work on SimpleIDE and PropellerIDE if the end goal is to do it all in a Chrome app? That's not the end goal, so their motivation is that Parallax and the community depends, funds, and supports their efforts to continue to provide the tools around which we base so many current and future efforts.
Ken Gracey
Amen brother
-Phil
Given the posts I read here about people having trouble with SimpleIDE/PropellerIDE the above seems like the more "simple" way to go.
@Phil and David,
Yes. As far as I can tell Chip designed the Spin system to be simple. No "projects" required.
My take on this is that:
a) As soon as you add buttons or a dialogue to select the language you want to use you have over complicated things for a user that expects a Spin tool. Or a C IDE.
b) You can of course use the same code base for the Spin and C and BASIC and whatever IDE and just build it to be specifically one or the other. But then you have tied all these things together and all releases of one depend on the others to be in good condition.
c) If you are building a multi-language IDE the question is why? There are already many IDEs out their that can do this. Just build on one of them.
d) Where is BradC? BST is brilliant.
As I mentioned above "We have no plans right now to support a combined tool effort between SimpleIDE and PropellerIDE." so I don't think you need to worry about this possibility. It would take immense user interface design to make these two things co-exist in one tool, which is why it's not likely to happen. The tools you see today will form the basis of our future tools, with improvements.
Some new tools are planned, like BlocklyProp, GroundStation etc, but nothing that combines Spin and C into a single code editor and IDE.
Ken Gracey
Yes please. I understand why PropTool was created. I can even, to a certain degree, understand SimpleIDE and PropellerIDE. But at the point that you start combining them and expanding the requirements, it makes less and less sense.
Of course no offense to Brett, jazzed, and whoever else has worked on these IDEs. But Kye had it right when he created OmniaCreator: there's no need to re-invent the wheel. If you want to go big (i.e.: projects, multi-lingual, C/C++ warnings & errors, syntax highlighting, autocompletion, and more) then use something that already exists and has been well-proven. QtCreator may not be my favorite IDE, but its worlds ahead of PropellerIDE and SimpleIDE.
It made sense to start from scratch when requirements were small and specific. But combining SimpleIDE and Propeller IDE is not very niche any more, and certainly not small. Build on Eclipse, QtCreator, Code::Blocks, or any number of other IDEs that already exist. The work Brett and jazzed have done is very cool... but absolutely silly given how many times other people have already done the same thing.
Or if what you really want is Arduino simplicity, then use the Arduino IDE. Don't forget that it, too, is open source. http://energia.nu/
1) A Spin IDE
2) A C/C++ IDE
3) An IDE that can handle both. The main reason this could be handy is that PropGCC and SimpleIDE allow you to include Spin code in your C/C++ projects. It would be nice to have the Spin syntax highlighting and other editor support available as well.
Yes, what we want is Arduino simplicity. At least as far as Spin goes. The Prop Tool and BST show how to do it.
When it comes to C/C++ it's not so clear to me.
@David Betz, That is exactly what I was arguing against. Tying them all together slows progress. And what is the point anyway when we have many IDE's out there already. That is exactly the kind of complication I'm arguing against.
A PropTool equivalent IDE that runs on Windows, Linux, Mac (as in bst)
A better inbuilt Terminal emulation (bst or better)
Compile time options (#ifdef, etc as in bst and homespun)
Listing (as in bst and/or homespun or similar)
Simple Macros
Source "includes" (as in homespun. Unsure if in bst)
I am sure all these would have consumed far less man hours and $ and seen much wider acceptance/use than has occurred in the IDEs discussed here. Even Roy's OpenSpin isn't getting much use due to poor IDE's.
To the list above, some form of Basic (such as Bean's plus extensions) would I am sure have been extremely popular. Just look at MMBasic on the PIC chips.
On top of all this, we had Ross's Catalina C which worked extremely well. It was never given much support by the powers to be. I can personally attest to it being an excellent product, having used it in a commercial product (on a Propeller with 512KB SRAM and SD mixed with PASM and connected to two other Propellers running a mix of Spin and PASM).
@Cluso99, now you are a bit unfair. Sure PropellerIDE is not as nice as BST, but quite nice already.
so it is - A PropTool equivalent IDE that runs on Windows, Linux, Mac (as in bst)
It does have a inbuild Terminal emulation and even multiple ones open at the same time.
Since PropellerIDE is using Roy's OpenSpin it does support #ifdef, listings and a simple preprocessor, Roy added all of this to OpenSpin already. You also can add additional library path info on the commandline of OpenSpin, not sure what "includes" you are missing, never used homespun.
Brett added subdirectories to object sources, Phil is not too happy about how, but it is there to test it.
So - almost there?
Mike