SimpleIDE Version 0-5-0 Available
jazzed
Posts: 11,803
Hi All,
Please download and test SimpleIDE version 0-5-0 from: http://propside.googlecode.com
This release includes many fixes and several new features. New features are:
Thanks,
--Steve
Please download and test SimpleIDE version 0-5-0 from: http://propside.googlecode.com
This release includes many fixes and several new features. New features are:
- Added Jen's beautiful program Icon - jury's still out on this
- Added File Menu Close and Close All
- Up to last 5 files tracked in File Menu
- Project Menu with New Project, Open Project, Save Project, etc....
- Added Workspace folder in Properties for New Project dialog
- Up to last 5 projects tracked in Project Menu
- Last directory tracking for file/project Open, Save As, etc...
- Find and Replace dialog Ctrl+F replaces old Find feature
- Added Board Type to project file save
- Added Ctrl+Tab for tab editor queue scrolling
- Added Source Browsing Ctrl+Left Click to find declarations
Thanks,
--Steve
Comments
This was based on the 5 minutes I had to look at the new build. It works great overall! The "New Project" dialog/process seems to work well.
-It took a while to realize it was creating a sub-directory, .side file, and .c with the same name, however that is "by design" (so you are not prompting for extra information).
-It looks like there are still some issues with colorizing the text. In comments, if the single line comment ("//"), and quotes are used in the comment, the code colorizes the quoted text like a string literal. This can be seen in the comments section of code like /C-VGA/vgademo.c
Minor things:
- It looks like the "help" and "about" both have content, however they are both different. Is one a placeholder? Are the actual help files going to be hosted on that Google site maybe?
- There was code in the workspace directory after a fresh install. Was that intentional? It looks like it is duplicates of what appear in sub directories (and things like pong.zip).
- The default board type is the "ASC" rather than the "QUICKSTART." I figured it was at least worth mentioning, since I would think either PROPBOE or QUICKSTART would be the most logical defaults, considering.
Thanks!
--trodoss
Excellent report and comments. Thanks for the feedback so far. Please beat it up more if possible.
Let me know if the Find Declaration source browsing features are intuitive enough.
I'll assume the "hang problems" are gone and will close the bugs without feedback.
The Serial Port Terminal is performing the best that I can get it to work on windows, unless there is a horrible problem, I'll consider the reported bugs fixed.
RE your comments:
-New Project process:
I'll add some text explaining what's happening.
-Colorizing:
Gee
-About/Help:
About is just the splash, program name/version, and program copyright.
Help has a help pointer and copyright information. Yes, actual help will be hosted.
-Code in workspace:
Sorry about that I forgot to check before making a package. Cleaned up now.
-Default Board Type:
The default board is based on the project opened. However PROPBOE could be selected by arrangement.
BTW, found a bug in "Set Project (F4)" this morning. I'll post a SimpleIDE.exe that fixes it later.
The bug happens if you do this sequence:
1. Menu-File-New
2. Edit file and Menu-File-Save (Ctrl+S in windows). Program asks user to name file and save as ....
3. Menu-Project-Set Project (F4) ... this should make a project named after the newly saved file, but doesn't.
I have ideas for future features, but can't commit to many right now.
The main things left to do are make Linux/Mac distributions and verify internationalization.
I've built/run on Fedora and Debian and need to make packages for them.
Others have built/run on Mac OSX and I'll need help with those packages.
Once the bug reports are all squashed, I'll probably make a 1.0 release.
Thanks,
--Steve
I've uploaded a debian-linux-i686 test package to try at
http://code.google.com/p/propside/downloads/list
This should also work with ubuntu-linux-i686.
You must have Propeller GCC in /opt/parallax to use the IDE.
A new i686 propgcc_v0_2_4 package will be uploaded later today.
An IDE dpkg for use with apt-get is being created.
Other packages for x86_64 and i686 fedora will also be created.
Thanks,
--Steve
Had time for a quick run on XP, which is my established Prop dev station right now. I'll do Win 7 over the weekend, as well as stuff some larger bits of code into it. I've some VGA graphics library code ready to tinker with.
Simple indeed! Well done so far.
I'll have some more feedback when I can get a longer stretch of time. It would be great to put "Done" in the log, like it appears in the the GUI screen border. I should know better, but I looked at the log for quite a while, before realizing it was actually done working! Sample screenie attached. Funny actually.
I like the icon, it's distinctive, and frankly that's all one needs to locate and use it.
I was able to create a project and author some code and have it build without really thinking about it too much.
I was not able to see a difference in the GUI when I fed it broken code. Sample screenie attached. Seems to me, I should see something indicating the program isn't viable, or a warning, or something. Maybe that's on the feature list. And maybe that's in the user guide too. I ran this report "fresh", just to capture impressions for you. Now I'll go and look.
Edit: I literally ran setup, slammed through the defaults, ran the program and did a few things. Very lean. I like that a lot.
Not at all. If anything I would add text to #1 "...where files will be stored.", but that's me. Not necessary at all.
I would recommend something I see one of the vendors I deal with doing: adding check boxes to the explanatory text. Like the moment the project workspace path is defined, the green check symbol appears, and it would appear where "1)" does, if it were indented a shade more. If it becomes undefined, or broken, a red "X" appears there, and the OK button won't become active until there are two green check boxes. This latches the user into either cancelling, or progressing, with feedback as to successful input.
On dialog open, it would look like what you've posted up, only "OK" wouldn't be active. The symbols appear after some input has happened. Essentially, trade input error messages on "OK" for feedback before allowing the "OK" to be executed.
-Ouch
-I see you added bad code to a file that was not compiled.
You have to save untitled as some file and either "Set Project" F4 or add the file to your existing project.
The only files that get built are ones listed in the side project. Not sure how exactly to make that clear.
-I like your suggestions on the new project dialog.
The easiest to quickly implement is setting cancel as default until the project parameters are ready.
I'll add todos for that and the check marks - of course i'll need check marks on the properties page too.
Thanks for your test drive time.
--Steve
SimpleIDE looks great!
I installed the win-setup. With Win7/64.
The hello.c could be downloaded to my demoboard and it worked.
But if I change the source it still loads the old a.out. I cannot find the new a.out. Should it be written to the "workspace"?
error: failed to open "a.out"
Thanks a lot!
Christof
Christof
Hi Christof,
Glad things are working now. I've been thinking about that a.out thing for a while. I'll probably remove it before builds since it's bound to cause more trouble as is. The new a.out should be written to the workspace/project folder where the .side project sits.
Let me know if you have any more trouble or concerns.
Thanks,
--Steve
Well, that makes sense now... Bet it would have after glancing through the docs too. (I won't until this evening) If I have a clarity idea, I'll post it.
The core problem is communicating project focus and then managing it. The application does communicate it nicely, but the user is free to just do something they won't find productive, which is the rub, because it's a friction point.
Three basic schools of thought on this.
One is to add features such that they can come to control the program in ways that will help them be productive. Give them options and add more verbose errors / hints to get them where they need to be. Features may be added to manage features... Thick.
A second is to limit actions, improve discoverability, leading them to a productive action. Identify one primary use case and nail it, leaving the user to adjust how they work and manage themselves, keeping application scope small, barrier to use low too, efficiency high, even though it might not address more complex use cases in an ideal way. It just works, and is lean, only necessary features are added and maintained. Make assumptions and just design them to be very good and livable assumptions, so that things remain lean and productive. User will adapt to workflow, instead of school number three below.
A third school of thought is to make some basic assumptions, and of course with that comes some bloat because different users would prefer to make different assumptions. Both one and three increase complexity, though they do also improve efficiency after a time. Basically one and three enlarge the scope of things with little tweaks here and there to deal with use cases. Features end up with lots of options, and there are some features to manage features. Thickest.
Might I suggest "friction free" as a guide to resolution of these things? I've seen this in action on some higher end CAD programs to great result! I have not been a fan for years, but I am a recent convert as I see new user / transitioning user adoption of complex software seriously improve. The metric I've used over the years is days of billable training per 100K of software sold. It's a third of what it was a few years ago. Impressive.
This is Simple IDE. Make some assumptions, and deny unproductive behavior. Any user who grows to be adept enough to feel over-constrained by this is ready for a real IDE, right? That is my take anyway. Besides, a lean tool is in scope, given a full featured, pro one is in progress.
Applying that to this use case would work along the lines of school of thought number two, where the application simply builds the project associated with the file that has the focus, and it dynamically updates the file tree on file tab focus change. (screenie attached for discussion)
I see the project name above the file tree. I would add Build Project = [name], which indicates what the build command will do.
Remove the "set project" option, as it won't be needed. If a user wants to build a project, they simply select a file tab associated with that particular project. Some flexibility is lost, but a feature goes away, and the discoverability goes up, in that quickly bonking on tabs will reveal this behavior, and it's friction free because no config options or decisions need to be made. Build will then just build.
In the case of an unsaved file being present when the user requests a build, ask them "save all tabs, or build from disk?" and call it good. There might be a more pure, friction free answer here, but I don't feel good about a "just save it" assumption, nor do I feel good about a back-door, build from RAM to file kludge that hides it. Going all or nothing reinforces the idea that it only makes sense to build from a known coherent state. A user could optionally save a tab or two, leaving one unsaved, and then build from disk anyway, and that's a niche case more than not. Pretty low friction there, IMHO.
If this level of feedback / suggestions is outta line, just let me know. I deal with UI issues a lot, and am sharing some of the productive trends I've experienced the last few years. Honestly, I like this application and would love it to be just nuts great, simple, fast.
Short story: Design that problem away. Edit: If possible, given all the necessary use cases. Thought about it this morning, and there may well be some use cases that don't work well. I don't know what is worth what.
It is nice to have the compiler options in a pane on the page, although having the ability to hide the left-hand panes in the main window would be nice (although not absolutely necessary) so that you can have the full window available for source code editing. I think of that more as "project (compile) settings." Putting it in a place (like a "project settings dialog," buried in another action) would make it much less flexible, so I would say don't move it...just give an option to hide it.
Glad to hear things are working. As for hiding, look at the attachment
I didn't mention this in the docs,but there is a grab bar between the panels. Mouse-over those areas and you will find them. Click and drag the project side panel and build status all the way left and down respectively - the panels will disappear. You can drag them back out/up.
The Windows7 scheme doesn't make the grab bar very clear like in the default Mac OSX and many Linux window managers.
Regarding "untitled *" tabs. I'm looking at creating a warning dialog to handle this and other changed tab editors' text.
Unfortunately unlike SPIN, C is a language that can have many modules that are only connected by the build process and just having the visible file be the one to compile is very impractical.
One could say put all your module code into headers, but that will just make lots of potential C customers angry. Some C++ users do put module code into headers, but I'm not sure I can justify forcing that practice on everyone. So unfortunately, the way it stands now is the way it will be.
I'm looking at adding some candy features once the Mac OSX package is ready. Some being considered are:
- Context sensitive library function help.
- Block indent.
- Editor Properties such as tab space count (tabs are replaced by spaces).
- Secret features.
Of the candy features, the first is most important to me because it forces me to do some special testing.Thanks,
--Steve
Jazzed, that makes a lot of sense. It just hit me this morning: This kind of thing could be resolved with a "Top 10 video" When you get farther down the road, maybe I can help produce one, or just do one. Ten things that will get you rocking on Simple IDE. Have it last 10 minutes, they watch it, done! We use these kinds of things all the time for the CAD / PLM stuff. Never tried it with something like this.
And what you just mentioned is why that kind of thing that keeps me from being a huge fan of the "school number two" above. I've seen it put to good use, but I've also seen stuff too dumbed down, limited. Sometimes it's a good path, other times not. Hope tossing it out there was not a worry.
FWIW: I'm doing some programming with it this weekend. With just the feature set it has right now, I like it a lot, because there is enough to get stuff done in a lean way, which keeps me on the task of C programming, not tool / config management. Highly desirable. That is actually a significant obstacle for those of us who jump in, want to do something, then get out and on to the next thing, whatever that is.
Outduino?
Here's a new dialog to warn against unsaved non-project files.
Forgot to mention the program needs some features for writing .pex files and running them from SD card.
There is also a list of minor enhancements and fixes to make before another release.
Hopefully I can finish these today ....
This is a feature request.
Can we have a setup option to change the IDE font size, some of us are getting on a bit and need to squint.
And also perhaps be able to set the font so I could use my preferred programming font i.e. Droid Sans Mon.
Regards
David
I'll look into adding a font dialog in the edit menu. I could use "propably" use ZoomIn/ZoomOut for font size control. No promises just yet ....
I've added font controls for selecting a font and for resizing in the editors.
Here's a Mac OSX snapshot:
Here's a Gnome Linux snapshot:
Here's a Fedora 16 KDE Linux snapshot:
Here's a Windows7 snapshot:
Excellent effort, is this a patch or is it in the full download from code.google?
David
Hi Martin,
Never thought about that actually, In the environments I use i.e. visual studio, keil etc I use I have always setup the syntax highlighter colors for strings and numerics etc.
You could pull the font into a font editor and add the line in the zero:)
Cheers.
Just a patch right now. Find attached.
Some bug fix info and explanations.
Added "Done. Build Succeeded!" to compiler status. If build fails, some basic guidance is provided.
Fixed string in one line comment highlighting // "hello".
New project dialog will not show OK until fields have reasonable data in them.
Source browsing: Back could return to the wrong line. That is fixed now. References to Find Declaration are now Browse Declaration. The "Back" arrow will be disabled if the Browser stack is empty.
Menu->Program replaces Menu->Debug. Menu->Debug is reserved for something else later on.
The blue COG (looks like a tire) replaces the old Set Project icon for clarity.
Build output files are now removed before the build so that old ones don't accidently get loaded.
I've added a new project option "SDCard Load Type" ... it will not work with the old propeller-gcc package. There are some issues we've had to fix and they are not ready yet.
Maybe this will help.