Perhaps that is a new feature of Qt4. Never was so before.
Yeah, bet it's for mobile / tablet, where pounding the CPU isn't desirable and or RAM consumption is a priority. GPU can crunch more, use less power than a CPU can, and do so in a smaller RAM foot print / performance metric needed. I don't know enough about QT to even start to look right now. Will be interesting to see what you find. I may go do some online digging just as an idle curio.
Well that was easy. Builds and runs out of the box on Debian 7. Well after fixing that .toASCII problem.
The dialog to find the compiler libs and library will have to go. That is not "easy"
Don't know where that missing gl problem came from. It's not used anywhere in the application code. Normally Qt will not have such a dependency unless you ask for it. Ah well.
Maybe don't statically link it, but do include it in the binary. If the compiler can't be fould, the IDE writes it, and a path. If it can be found, it gets used?
I use the top object feature of PropTool all the time, and was going to suggest it to David when I saw him complaining about the compiling/running the current tab issue. Anyway, you all did...
The compile from memory/open tabs feature comprises two things (one you may not be aware of), they are actually one in the same but it's important to be aware of the two cases.
1. It uses the currently open in memory version of a given file instead of the on disk one. This is the obvious known aspect.
2. The currently opened versions of files will be used even if they are from different paths than the current path or library path(s). This can be useful, but also cause unexpected results if you close a tab and compile in a different version.
I like the feature a lot, but I also feel that we should make it an option that defaults to off. And when it's off, if you compile the editor should save currently open files before compiling (unlike when it's on).
Option default to build from RAM to ON is fine. I expect that it will make it easier to do other non-user things although supporting persistent options is something of a pain.
As far as the dialog ... theoretically the only time you will ever see that is if the compiler or loader are not found in the package. The alternative is to complain to the user any time the compiler or loader is not found when they try to compile or load.
Roy wants to integrate the compiler as a library which is perfectly fine for a Spin IDE build. However, it is not fine for a C, PropBasic, blah, blah IDE compile time option build, and thus we need a way to select a compiler or loader if it is not found.
I would argue back that easy in the name right now was not intentional.
I don't think the goal is to make a easy/simple ONLY tool. The goal is to make a replacement for PropTool that is cross platform, and has improvements.
Heater, you are straying into the false hope land of GPL and RMS with this taking things to extremes at the expense of anything else.
The real goal is for all users to have a good experience coding spin on whatever platform they have. Those users include everyone from beginners to professionals, and while you could argue that they should have the same set of features (some compromise set that satisfies both somehow), I feel pretty strongly that there are some things that should not be compromised on and instead should be options.
Seriously, I work with hundreds of coders, and none of them have the same preferences for how their development stuff is set up. It's just plain wrong to think you can force everyone down a single solution and make them all happy. You'll just end up with less users for this tool, and more tools as people make what they want.
I will constantly argue against any options. Every option takes away from "easy".
"easy" is : Open tool, type code, hit run.
Anything else should be looked at very carefully.
I'm not really sure why options that are switched off by default necessarily complicate the interface. Lots of not very technical people can deal with Microsoft Word and it has a zillion options most of which get ignored by most users. The same is true of web browsers. I don't think it's necessary to dumb down this IDE but I do think that simple defaults are important. Most people will never use anything but the defaults anyway.
This might be a weird idea how about sneaking options into the spin source code as comments?
When users get savvy enough to want to change things they will be savvy enough to write such comments at the top of their main module.
I like the idea that there are no option dialogues and menus and check boxes in the GUI. "Type and run" as I always say.
Having any files around to remember options is a pain, smacks of a "project file" already. And we don't want to get into saving things in the windows registry and such.
I'm not sure I would go with having the compiler/loader as a library. As long as the binaries are shipped with the package everything is good to go.
Having any files around to remember options is a pain, smacks of a "project file" already. And we don't want to get into saving things in the windows registry and such.
Total bulls**t. Even Propeller Tool uses persistent options in a registry.
I would argue back that easy in the name right now was not intentional.
From Jazzed's description of how the name came to be, it seems to be very intentional.
But if not let's go back to "Propeller IDE". (We should do that anyway).
If the concept here is not "easy" then actually what is the point of the whole project? Jazzed has already made Simple IDE which works perfectly well. Right?
You are right "serious coders" will always customize their tools the way they like. In my experience they will not even use a thing like Simple IDE or this effort, they will tweak Eclipse or Sublime or whatever they like and use that. Hey, even vim has Spin syntax highlighting
Given all that why put the effort in to build yet YAIDE, Yet Another IDE? The world has dozens already.
The "easy" concept is valid. Like the Ardunino IDE. See how successful that has been.
David,
MS Word is a very good example of why we don't want to go down that road. No body kows how to use that thing.
Speaking of projects, will this tool have an optional "projects" selection? I remember BST had an optional "projects" selection, how many people used it, I do not know, but I found it to be a very good thing to use. Since I do have and have had problems with top file business, I would not mind seeing a project option where you could have your first file created being top file and not worry about what is being compiled. I guess then you would need something that would allow you to just compile a specific object if necessary.
MS Word is a very good example of why we don't want to go down that road. No body kows how to use that thing.
I'm certainly not suggesting something as complex as Word. My point is that even all of that complexity in Word doesn't prevent it from being use by almost everyone. Given that, how can a single "options" dialog render PropellerIDE too complex for ordinary mortals?
It's open as to where options are persisted, but you do need some way to persist options across a session and across a version install to some degree.
It's an editor, people are going to want to change the # of spaces used for tabs, the background colors for the Spin sections (if a user is colorblind, the default colors may look the same to them), font sizes, etc.
As folks add features, some of them may require a persistence mechanism. May as well start it now so it is built into the tool rather than bolted on later.
This is answered in the Requirements page (the other user guide that nobody reads).
Yes, I did read it and remember seeing it in there, I thought I would bring that up again just to see what sort of reaction it would get. But, the people that I thought would react have not responded, must be asleep.
Yes, I did read it and remember seeing it in there, I thought I would bring that up again just to see what sort of reaction it would get. But, the people that I thought would react have not responded, must be asleep.
Ray
I'm sorry Ray, may have been a little short.
I wonder about that sleeping too.
Thanks for wanting to continue the dialog. If there is one thing I've learned over the last several years, it's that Parallax software is expected to not be project based. That is how the Basic Stamp editor works. It is easy for even the most casual observer to use. I've seen the expectation in action.
For example, Parallax has lots of customers who teach the Basic Stamp curriculum. I got to sit in on one of the Educator's Courses one day. To my amazement even after being told that "this is the way it works", these teachers still thought that they were using a product that would behave like the Basic Stamp out of force of habit. By the time I saw this, it was too late to change SimpleIDE because of all the other stuff I had to add.
The thing is, if Parallax sells something, it should be in line with expectations of the brand regardless of how others think it should work. The quandary is that C is a professional language* with many preconceived notions, and Parallax's reluctance to cater to those notions puts it at a major disadvantage in penetrating that vast market, but helping students of all ages learn about programming makes opportunities available to those from 9th grade Advanced Placement school programs to those who want to understand a syntax that is available practically unaltered in a dozen or so languages.
As soon as we have something going with this IDE, SimpleIDE will have the Spin project support totally removed unless I'm vetoed. SimpleIDE is designed for C programs, it will use projects. Now, since we have the Simple Library concept, that can be used in an environment like the Propeller Spin IDE, and some day a Propeller C IDE may be project-less.
Hope that helps.
--Steve
Note* There is an entire professional ecosystem built around C/C++, and people are very serious about what they do, and how they do it. I'm sure Roy understands all this having worked with hundreds of developers like I have. It is impossible for a permanent one-man-show or inexperienced hobbyist to understand this issue.
In my experience C/C++ programmer's don't give two hoots about an IDE. They have their favourite editors and tools, which may actually be IDE's, and use those. At the end of the day the project is built from the command line. As I did just now. Put the easyside code on the Pi, qmake, make, fix the .toAscii problem in vim, make, done.
Where that leaves SimpleIDE I don't know. As a soft start to those new to C and/or new to the Propeller it's brilliant. Is it worth growing into an all singing all dancing Eclipse? I guess that's up to you. I think it's great anyway.
My favorite editor for C/C++ coding is Visual Studio 2013. Part of the reason is that it's got great syntax highlighting for the language, excellent completion system that knows the context and language well enough to give really good result (some of this comes from an extension I use with it called VisualAssistX), and it actually compiles the code as you type and gives you feedback in editor about the results (squiggly underlines and tooltips). It makes it such that when I write code, it's much easier to get it right quicker and also implement things the right way the first time instead of short cutting and fixing later. I could probably configure VS2013 to let me edit and compile Spin/PASM code but it would lack a great deal of it's features that are present for C/C++. The same could be said for other editors and IDEs.
I want a Spin/PASM IDE that has that level of powerful understanding of the language, so that it can make my coding experience that much better. However, I am very cognizant of the new user (got a lot of first hand experience with it from the First Spin and First C podcasts, among other things), so obviously I don't want to make VS for Spin, but I think we could bring in some of the intelligence/power to make things better.
So, I do want to make an IDE that makes Spin/PASM coding easier/better, I just don't like the idea of calling it easy/simple and having that strangle the development (or have the name just be wrong).
I think we do need to be careful about what options we do have, but I don't think we should eliminate them.
I, also, think that we should first focus on making this a Spin/PASM IDE that rocks, and if later on people want to take it and add in or fork to make a XBasic variant or "whatever language" variant, then they can.
1) Syntax highlighting
2) Code completion system
3) Feedback in the editor (squiggly underlines..)
4) Powerful understanding of the language
I think all these things are great.
Syntax highlighting is a given now a days.
The others require more than just parsing the source or running over it with a few regexps. Things like use of undefined variables, unused variables, wrong number of parameters, etc, etc, require some steps toward compilation as you type, if not actually trying to generate code yet.
Thing is, this all makes getting started easier for the user. Type code, see red squigglies, fix it up, when it's clean hit the compile/download/run button.
So that is all good. Makes things easier for the user, makes things harder for the tool builders but there we are.
When I harp on about "easy", simplicity, KISS, I mean let's not have a bunch of dialogues that need to be filled in before you can start to type your code. Let's not have dozens of options for this and that, that have to be right before anything works.
An example of that is serial port set up. I don't actually want to select the right port and baud rate etc. I just want to hit "run" and get action.
The Spin language itself promotes such simplicity by dictating the formatting you will use. You have no choice there, no confusion.
The problem at hand for the user is programming in Spin and getting their Propeller project to work, not fighting with the tool. To do that all they need is the language and the "run" button.
The UX buzzword for these conceps are "friction free", along with the companion, "sticky" and together they hint at something a user will use, see success and then rapidly adopt.
Interestingly, applying the two together can often qualify features, their initial and sustained value very easily.
An example that seems like a good idea, but actually ends up a net negative, is the getting started hand holding dialogs, hints and tutorial kinds of things once often seen. The user gets yanked from context state to context state, all painful, despite the seemingly obvious value of helping them in context.
Finally, there is "fail gracefully", an example would be something like just initalizing the environment on first run, so it just works as opposed to asking questions all of which can be sorted out later when the user is in that context. Another would be to proceed on a warning without requiring input to process. Just display it and keep moving. When they are in the mood to wonder, they will explore then.
Heater expressed some of this with, "start it, type code, run" which does embody most of these. I would add, supply sample code so they could just start it up and run to be a purist. In this case, I'm not suggesting that, just highlight how the thinking goes...
I think we are on the same page, Heater. I want the thing to work without needing to change any options too. I just want to be able to go change some options if I so desire, and by some, I mean on the order of a single settings dialog with a small number of options that all default to sensible things when you first install.
Maybe people here trying to build a replacement for the PropTool should use the PropTool for a moment.
Examples:
compile Top versus compile current.
compile current is F8, F9, F10, F11
compile Top is ctrl-F8, ctrl-F9, ctrl-F10, ctrl-F11
all found in the Run Menu.
Set Top Object file is found in the File Menu and has the shortcut ctrl-T.
So why should F9 compile the top object and not the current tab? Just use ctrl-F9. It is there to compile top. Whatever tab you have currently open.
.
This is not supposed to sound like a rant. If it does please excuse me.
I just really like the simplicity of the PropTool and think that Parallax did a great job there.
Maybe people here trying to build a replacement for the PropTool should use the PropTool for a moment.
Examples:
compile Top versus compile current.
compile current is F8, F9, F10, F11
compile Top is ctrl-F8, ctrl-F9, ctrl-F10, ctrl-F11
all found in the Run Menu.
Set Top Object file is found in the File Menu and has the shortcut ctrl-T.
So why should F9 compile the top object and not the current tab? Just use ctrl-F8. It is there to compile top. Whatever tab you have currently open.
.
This is not supposed to sound like a rant. If it does please excuse me.
I just really like the simplicity of the PropTool and think that Parallax did a great job there.
Enjoy!
Mike
That functionality is fine if we carrry it forward to PropellerIDE. I actually knew about this at one time but had forgotten about it since I hardly ever use Propeller Tool because it doesn't run on the Mac.
Comments
The dialog to find the compiler libs and library will have to go. That is not "easy"
Don't know where that missing gl problem came from. It's not used anywhere in the application code. Normally Qt will not have such a dependency unless you ask for it. Ah well.
Turns out the GL dependency is nested deep inside from the QtWidgets header. Odd.
The compile from memory/open tabs feature comprises two things (one you may not be aware of), they are actually one in the same but it's important to be aware of the two cases.
1. It uses the currently open in memory version of a given file instead of the on disk one. This is the obvious known aspect.
2. The currently opened versions of files will be used even if they are from different paths than the current path or library path(s). This can be useful, but also cause unexpected results if you close a tab and compile in a different version.
I like the feature a lot, but I also feel that we should make it an option that defaults to off. And when it's off, if you compile the editor should save currently open files before compiling (unlike when it's on).
I understand. Was referring to the openspin
So was I.
Roy,
I will constantly argue against any options. Every option takes away from "easy".
"easy" is : Open tool, type code, hit run.
Anything else should be looked at very carefully.
As far as the dialog ... theoretically the only time you will ever see that is if the compiler or loader are not found in the package. The alternative is to complain to the user any time the compiler or loader is not found when they try to compile or load.
Roy wants to integrate the compiler as a library which is perfectly fine for a Spin IDE build. However, it is not fine for a C, PropBasic, blah, blah IDE compile time option build, and thus we need a way to select a compiler or loader if it is not found.
I don't think the goal is to make a easy/simple ONLY tool. The goal is to make a replacement for PropTool that is cross platform, and has improvements.
Heater, you are straying into the false hope land of GPL and RMS with this taking things to extremes at the expense of anything else.
The real goal is for all users to have a good experience coding spin on whatever platform they have. Those users include everyone from beginners to professionals, and while you could argue that they should have the same set of features (some compromise set that satisfies both somehow), I feel pretty strongly that there are some things that should not be compromised on and instead should be options.
Seriously, I work with hundreds of coders, and none of them have the same preferences for how their development stuff is set up. It's just plain wrong to think you can force everyone down a single solution and make them all happy. You'll just end up with less users for this tool, and more tools as people make what they want.
Total bulls**t. Even Propeller Tool uses persistent options in a registry.
But if not let's go back to "Propeller IDE". (We should do that anyway).
If the concept here is not "easy" then actually what is the point of the whole project? Jazzed has already made Simple IDE which works perfectly well. Right?
You are right "serious coders" will always customize their tools the way they like. In my experience they will not even use a thing like Simple IDE or this effort, they will tweak Eclipse or Sublime or whatever they like and use that. Hey, even vim has Spin syntax highlighting
Given all that why put the effort in to build yet YAIDE, Yet Another IDE? The world has dozens already.
The "easy" concept is valid. Like the Ardunino IDE. See how successful that has been.
David,
MS Word is a very good example of why we don't want to go down that road. No body kows how to use that thing.
Jazzed, I guess that's a "no" then
Ray
It's an editor, people are going to want to change the # of spaces used for tabs, the background colors for the Spin sections (if a user is colorblind, the default colors may look the same to them), font sizes, etc.
As folks add features, some of them may require a persistence mechanism. May as well start it now so it is built into the tool rather than bolted on later.
I have here a Raspberry Pi hooked up to a 27" Samsung monitor.
easyside compiled out of the box, aside from that pesky .toLatin1 issue.
It runs full screen into the frame buffer from the command line. I have no X running here!
Fabulous.
I have no keyboard or mouse hooked up so I can't tell if it actually works properly yet...
(I start it from an ssh session)
If you were to write a User Guide to Writing Requirements would that mean it never, EVER gets read??
Ray
I'm sorry Ray, may have been a little short.
I wonder about that sleeping too.
Thanks for wanting to continue the dialog. If there is one thing I've learned over the last several years, it's that Parallax software is expected to not be project based. That is how the Basic Stamp editor works. It is easy for even the most casual observer to use. I've seen the expectation in action.
For example, Parallax has lots of customers who teach the Basic Stamp curriculum. I got to sit in on one of the Educator's Courses one day. To my amazement even after being told that "this is the way it works", these teachers still thought that they were using a product that would behave like the Basic Stamp out of force of habit. By the time I saw this, it was too late to change SimpleIDE because of all the other stuff I had to add.
The thing is, if Parallax sells something, it should be in line with expectations of the brand regardless of how others think it should work. The quandary is that C is a professional language* with many preconceived notions, and Parallax's reluctance to cater to those notions puts it at a major disadvantage in penetrating that vast market, but helping students of all ages learn about programming makes opportunities available to those from 9th grade Advanced Placement school programs to those who want to understand a syntax that is available practically unaltered in a dozen or so languages.
As soon as we have something going with this IDE, SimpleIDE will have the Spin project support totally removed unless I'm vetoed. SimpleIDE is designed for C programs, it will use projects. Now, since we have the Simple Library concept, that can be used in an environment like the Propeller Spin IDE, and some day a Propeller C IDE may be project-less.
Hope that helps.
--Steve
Note* There is an entire professional ecosystem built around C/C++, and people are very serious about what they do, and how they do it. I'm sure Roy understands all this having worked with hundreds of developers like I have. It is impossible for a permanent one-man-show or inexperienced hobbyist to understand this issue.
In my experience C/C++ programmer's don't give two hoots about an IDE. They have their favourite editors and tools, which may actually be IDE's, and use those. At the end of the day the project is built from the command line. As I did just now. Put the easyside code on the Pi, qmake, make, fix the .toAscii problem in vim, make, done.
Where that leaves SimpleIDE I don't know. As a soft start to those new to C and/or new to the Propeller it's brilliant. Is it worth growing into an all singing all dancing Eclipse? I guess that's up to you. I think it's great anyway.
I want a Spin/PASM IDE that has that level of powerful understanding of the language, so that it can make my coding experience that much better. However, I am very cognizant of the new user (got a lot of first hand experience with it from the First Spin and First C podcasts, among other things), so obviously I don't want to make VS for Spin, but I think we could bring in some of the intelligence/power to make things better.
So, I do want to make an IDE that makes Spin/PASM coding easier/better, I just don't like the idea of calling it easy/simple and having that strangle the development (or have the name just be wrong).
I think we do need to be careful about what options we do have, but I don't think we should eliminate them.
I, also, think that we should first focus on making this a Spin/PASM IDE that rocks, and if later on people want to take it and add in or fork to make a XBasic variant or "whatever language" variant, then they can.
I'm totally with you. You mentioned:
1) Syntax highlighting
2) Code completion system
3) Feedback in the editor (squiggly underlines..)
4) Powerful understanding of the language
I think all these things are great.
Syntax highlighting is a given now a days.
The others require more than just parsing the source or running over it with a few regexps. Things like use of undefined variables, unused variables, wrong number of parameters, etc, etc, require some steps toward compilation as you type, if not actually trying to generate code yet.
Thing is, this all makes getting started easier for the user. Type code, see red squigglies, fix it up, when it's clean hit the compile/download/run button.
So that is all good. Makes things easier for the user, makes things harder for the tool builders but there we are.
When I harp on about "easy", simplicity, KISS, I mean let's not have a bunch of dialogues that need to be filled in before you can start to type your code. Let's not have dozens of options for this and that, that have to be right before anything works.
An example of that is serial port set up. I don't actually want to select the right port and baud rate etc. I just want to hit "run" and get action.
The Spin language itself promotes such simplicity by dictating the formatting you will use. You have no choice there, no confusion.
The problem at hand for the user is programming in Spin and getting their Propeller project to work, not fighting with the tool. To do that all they need is the language and the "run" button.
Interestingly, applying the two together can often qualify features, their initial and sustained value very easily.
An example that seems like a good idea, but actually ends up a net negative, is the getting started hand holding dialogs, hints and tutorial kinds of things once often seen. The user gets yanked from context state to context state, all painful, despite the seemingly obvious value of helping them in context.
Finally, there is "fail gracefully", an example would be something like just initalizing the environment on first run, so it just works as opposed to asking questions all of which can be sorted out later when the user is in that context. Another would be to proceed on a warning without requiring input to process. Just display it and keep moving. When they are in the mood to wonder, they will explore then.
Heater expressed some of this with, "start it, type code, run" which does embody most of these. I would add, supply sample code so they could just start it up and run to be a purist. In this case, I'm not suggesting that, just highlight how the thinking goes...
Examples:
compile Top versus compile current.
compile current is F8, F9, F10, F11
compile Top is ctrl-F8, ctrl-F9, ctrl-F10, ctrl-F11
all found in the Run Menu.
Set Top Object file is found in the File Menu and has the shortcut ctrl-T.
So why should F9 compile the top object and not the current tab? Just use ctrl-F9. It is there to compile top. Whatever tab you have currently open.
.
This is not supposed to sound like a rant. If it does please excuse me.
I just really like the simplicity of the PropTool and think that Parallax did a great job there.
Enjoy!
Mike
I've used it often over the last 6 years, and still use it. Having a good C programming environment has made it less important to me however.
How many people here never use the PropellerTool ?