I got my concoction to run as expected, thanks to Chris Wardell, I can bypass the command window start up. For the pesky little xBasic stuff, I just duplicate what I put in for the Spin part. I got a copy of openspin, and propeller-load which seems to make everything work on my windows box. I also ran a little blinker.spin program which also worked as expected, so far so good.
I guess there is the question of what the base program is going to look like before it goes full tilt Spin/PASM? Since this has the potential of working for other compilers, will the actual control of what you want to run be centered on the selection of what goes into the Properties window? Or will the base copy just have that feature? Or something new and different?
As for the name, now I am thinking Ptc, where the P could be interpreted as Propeller or Parallax or Programer or ... , the tc would stand for "tool chain". So the whole thing could be "Ptc Spin inside" or "Ptc (favorite compiler) inside". Or just leave off the "inside" thing.
Now onto the Linux concoction, where do I find an openspin and propeller-load versions that would run in linux? Or how is this to be done?
Now, I get why it is a trip up. Most environments write to storage, then compile. Prop Tool does not.
Here is why I like build from RAM: ...
I guess I misunderstood this requirement. I'm not objecting to compiling from RAM. What I don't like is that the Propeller Tool treats whatever file is currently displayed as the "top file". This means that if I have a project that uses multiple objects (almost every Spin project!), and I happen to be working on code in one of the sub-objects and want to try out my changes, I have to remember to select the main file in the editor before compiling. I think the default should be that whatever file is open first becomes the "top file" and all compiles are based on that no matter what file happens to be selected in the editor at the moment. Pretty much every single time I use the Propeller Tool I end up trying tor run some sub-object by mistake.
For the loader you will find it in the propgcc source code. Check that out from here: https://code.google.com/p/propgcc/source/checkout You don't need to build or install propgcc but the loader is in the source tree.
I guess I misunderstood this requirement. I'm not objecting to compiling from RAM. What I don't like is that the Propeller Tool treats whatever file is currently displayed as the "top file". This means that if I have a project that uses multiple objects (almost every Spin project!), and I happen to be working on code in one of the sub-objects and want to try out my changes, I have to remember to select the main file in the editor before compiling. I think the default should be that whatever file is open first becomes the "top file" and all compiles are based on that no matter what file happens to be selected in the editor at the moment. Pretty much every single time I use the Propeller Tool I end up trying tor run some sub-object by mistake.
David,
I took it the way you did. Whatever tab has "focus" gets compiled when you hit a compile button. It removes the project aspect and lets you have several programs in the works at any one time. Any "project" structure comes solely from the list of objects within a Spin file. I use this feature when playing around with Spin (I don't call what I do developing). I'll often have a null Spin program open in addition to whatever I'm working on. I use it to effectively idle the prop and prevent any mishaps if it gets turned on ....especially good with a robot, just load that program before you put it to bed if what you are working on is mechanically troublesome.
I hadn't even considered the issue Potatohead brought up.
Steve, can you clarify the requirement? It would be terrible to implement the wrong thing because of ambiguous requirements....not that things like that ever happen in real life!
In EzIDE I cut/pasted a path from windows explorer for openspin which of course used "\" instead of "/", the path was accepted by the dialog but then I get an error about not finding the compiler when I build.
Changing the "\" to "/" solved the problem.
I would think we would want to allow windows users to use 'normal' windows paths instead of forcing users to use the "/" (normal with respect to the windows world).
I took it the way you did. Whatever tab has "focus" gets compiled when you hit a compile button. It removes the project aspect and lets you have several programs in the works at any one time. Any "project" structure comes solely from the list of objects within a Spin file. I use this feature when playing around with Spin (I don't call what I do developing). I'll often have a null Spin program open in addition to whatever I'm working on. I use it to effectively idle the prop and prevent any mishaps if it gets turned on ....especially good with a robot, just load that program before you put it to bed if what you are working on is mechanically troublesome.
I hadn't even considered the issue Potatohead brought up.
Steve, can you clarify the requirement? It would be terrible to implement the wrong thing because of ambiguous requirements....not that things like that ever happen in real life!
Unfortunately, I think both things are wanted. Compiling from RAM seems like a good feature to me but the idea of loading whatever tab happens to be open in the editor is something I'll never get used to and that I think is a bad idea. I can't imagine that many people actually develop more than one program at the same time and for those who do having a separate instance of SimpleIDE running would probably be a better solution. I know I'll never win this argument because the way the Propeller Tool works is considered sacred around here but I still think it's a mistake. Sorry!
I've encountered this "feature" of the Prop Tool quite often. I'll edit a sub-object, hit F10, and then wonder why my program isn't responding. However, I have also used this feature intentionally with F8 to see how large a sub-object is and to make sure it compiles OK without compiling the entire project. It might be nice to be able to designate the top object in the IDE so that F10 and F11 start with the designated top object. F8 should still start with the current file rather than the top object.
EDIT: Designating the top object could be optional. If a top object isn't identified then the IDE would work just like the Prop Tool does now. That is, F10 and F11 would start compilation from the current file.
I've encountered this "feature" of the Prop Tool quite often. I'll edit a sub-object, hit F10, and then wonder why my program isn't responding. However, I have also used this feature intentionally with F8 to see how large a sub-object is and to make sure it compiles OK without compiling the entire project. It might be nice to be able to designate the top object in the IDE so that F10 and F11 start with the designated top object. F8 should still start with the current file rather than the top object.
That sounds like a good compromise. Also, I think the "top object" could automatically be set to the first file the user opens.
Designating the top object could be optional. If a top object isn't identified then the IDE would work just like the Prop Tool does now. That is, F10 and F11 would start compilation from the current file.
I just tried installing and running Qt5 64-bit on my xubuntu box, an interesting adventure to say the least. After I finally found the Creator Icon and was able to start it, the run process ended with an error, something along the lines of C++ compiler not found, use kit to change. I finally found this thing 'kit' , and it was showing that there was no g++ 64-bit compiler available. So, before I do an uninstall of Qt5 64-bit, and install Qt5 32-bit, is that the real problem? I am not finding any real joy with this Qt5 for Linux, it is almost becoming a hassle.
Don't they make software packages anymore where at compile time you just choose your target OS? It seems like that would solve a lot of problems and would be very convenient, but I digress.
I'm not a real developer but I'm also not project oriented like many people are. I hate going into an IDE/development tool/whatever and having to create a project whenever I want to do something new. If you want to do something quick, you shouldn't have to go through the project ritual. I think it is easier to see a list of tabs across the top with different programs in them than look at different instances of a tool to find the one you want. I can see having a "full version " spin file, a "motors only" spin file and a "sensors only" version and some of the supporting objects and also the important "empty loop" spin file all at the same time and wanting to compile and load any one of them.
I think it is ingrained in the communities and the tools they are used to. If you never had projects and got used to doing things (productively) with multiple "top level" programs open at the same time, then you will have problems adjusting to a project oriented environment....likewise, if you have always had projects in your life and can't imagine just opening up multiple programs and compiling them...well, you will have problems adjusting to the non-structured, no-project world. Neither is better or worse, just different.
I don't think a new, replacement tool for the Propeller Tool can force a project oriented paradigm onto Spin users just because.....I can see the pushback if you are used to just starting to create a Spin program, refer to a few of your favorite objects and start writing code ALL IN ONE FILE and now are being told you need to create a Project file, create your new source file, somehow associated the objects you want to use with the project and then if while working on this you want to create a little stub to test something, you need to open a new instance of the tool and then go through the entire new project process just to try something?
I don't think it is a mistake to give users tools that work how they are used to working.
I am not finding any real joy with this Qt5 for Linux, it is almost becoming a hassle.
That is a shame. Mostly it "just works". Don't forget Qt5 is very new. Linux distros like Debian don't even have a package for it yet. So we are all treading new ground here.
Before uninstalling 64 bit Qt5 why not just install a 64 bit g++? Surely its only a case of "apt-get install g++". I cannot imagine Ubuntu does not have a compiler.
Don't they make software packages anymore where at compile time you just choose your target OS?
Did they ever make tools like that? Who "they" anyway?
Microsoft for sure has never done that.
The Qt guys have been working on it for years and made a wonderful cross platform tool. It's just very hard what you are asking for is an order of magnitude harder again.
Designating the top object could be optional. If a top object isn't identified then the IDE would work just like the Prop Tool does now. That is, F10 and F11 would start compilation from the current file.
+1
The things people think of when you are typing a rant!!
I'm not a real developer but I'm also not project oriented like many people are. I hate going into an IDE/development tool/whatever and having to create a project whenever I want to do something new. If you want to do something quick, you shouldn't have to go through the project ritual. I think it is easier to see a list of tabs across the top with different programs in them than look at different instances of a tool to find the one you want. I can see having a "full version " spin file, a "motors only" spin file and a "sensors only" version and some of the supporting objects and also the important "empty loop" spin file all at the same time and wanting to compile and load any one of them.
I think it is ingrained in the communities and the tools they are used to. If you never had projects and got used to doing things (productively) with multiple "top level" programs open at the same time, then you will have problems adjusting to a project oriented environment....likewise, if you have always had projects in your life and can't imagine just opening up multiple programs and compiling them...well, you will have problems adjusting to the non-structured, no-project world. Neither is better or worse, just different.
I don't think a new, replacement tool for the Propeller Tool can force a project oriented paradigm onto Spin users just because.....I can see the pushback if you are used to just starting to create a Spin program, refer to a few of your favorite objects and start writing code ALL IN ONE FILE and now are being told you need to create a Project file, create your new source file, somehow associated the objects you want to use with the project and then if while working on this you want to create a little stub to test something, you need to open a new instance of the tool and then go through the entire new project process just to try something?
I don't think it is a mistake to give users tools that work how they are used to working.
I didn't suggest a project oriented interface. A single Spin file contains all that is needed to identify any objects that it depends on. What I am suggesting is that there be a way to say which Spin file is the top level file so the program gets compiled correctly even if you are editing one of the sub-objects at the time you hit the compile button.
I didn't suggest a project oriented interface. A single Spin file contains all that is needed to identify any objects that it depends on. What I am suggesting is that there be a way to say which Spin file is the top level file so the program gets compiled correctly even if you are editing one of the sub-objects at the time you hit the compile button.
That's why I like Dave Hein's solution. I think it is the best of both worlds.
@David -- Well, guess we got to have a chat about build from RAM. lol I agree with you, and it has bit me too. Now, I do sometimes have a couple of things going, and need to build "with tab as top", but I wouldn't miss it either. Bit me in the same way. Every single time too. A "set as top" function would get rid of that, allowing for multiple things going on at once, but really just building from the real top would be the best, regardless of the state of the tabs. Agreed.
@Heater -- Yes! Sublime is well, sublime! The tracking feature is particular nice, because I no longer have to put a window up running tail -f
I'm happy to work either way, and I do plan on getting it all moved over into Sublime, for the features you mentioned, among many others. My points raised really are about new users and how much they have to know to get moving. They can know less and discover more in a more recoverable way with the build from RAM feature. That's my observation having been one and worked with a few in the past. I'm not going to write much about it going forward though.
Seems you and I agree about git and friends. Yes! In the MCAD world, this same problem exists with all the same issues. It's been solved with file based management tools, and users have to understand caches, states, repositories, projects, groups, users, and all manner of other things to work with heirachies of files which form parts, assemblies, drawings and other constructs. It really is a PITA. No MCAD users do it command line. Those tools never did exist, and the binary nature of the files has always prevented git and friends from making too much sense, due to their lack of an ability to parse the binary blobs and pluck out bill of material data, and inter-file geometry references, which is always needed to understand what is what and where and who drives who in the mess of things.
However, there was one really great program that had data management built in. No way to get out of using it. And using that thing was awesome! I taught this material for many years. Still do. And users of that program always had the best time, able to do very complex things, never even worried about a path name! They didn't even have to worry so much about filenames. I've long thought somebody someday would build an IDE that embodies the same basic concept. For newbies, this sort of thing could be awesome. I would help on such a project too. What would happen is this: They would get up to speed managed, and do so very easily. At that point, they would not even imagine working with a mess of files, and would have revisions and such built in to their very basic thought process. Powerful stuff, should it ever happen in this dicipline, IMHO.
In any case, I just wanted to highlight what I've observed about people and how they will tend to work with the build from RAM feature. I don't plan on making a mess of the thread, etc... over it.
The problem was that xubuntu does not have g++ installed, amazing, so once I did that, then everything went much better. The next big problem is this error, could not find or it is not there, gl.h. The error pointed to gopengl.h line 110 -> # include <GL/gl.h>.
I think that at this point I will wait for the next version of the ide code, then I can try this again. Since things will be changing maybe this error will go away.
I guess now that this project is underway maybe it would be good for people to say what they're interested in working on. To start, I'm interested in working on the loader and terminal emulation. I have an idea that it might be possible to create a separate loader/terminal GUI that could either be used in conjunction with PropellerIDE or by itself. PropellerIDE would still be responsible for all program editing and compiling but it would launch this loader/terminal GUI to handle program loading and terminal emulation. I'd plan to write this separate loader/terminal program using Qt and the terminal program would support Parallax PST emulation as well as VT100/ANSI emulation at the user's choice. The nice thing about having loading and terminal emulation in the same program is that it will reduce or eliminate any delay required before the user's program can produce terminal output.
Designating the top object could be optional. If a top object isn't identified then the IDE would work just like the Prop Tool does now.
A top object can be designated in the PropellerTool I use. Compiling top is done with CTRL+F*. This is not Mac compatible though because it uses lots of F keys for system things. I'll make top file compile a future requirement; it won't be in the first cut.
In EzIDE I cut/pasted a path from windows explorer for openspin which of course used "\" instead of "/", the path was accepted by the dialog but then I get an error about not finding the compiler when I build.
Thanks CT. I'll look at that. It seems to be handled Ok in SimpleIDE ... I made a change in that area thinking it was superfluous code.
I took it the way you did. Whatever tab has "focus" gets compiled when you hit a compile button. It removes the project aspect and lets you have several programs in the works at any one time. Any "project" structure comes solely from the list of objects within a Spin file.
...
Steve, can you clarify the requirement? It would be terrible to implement the wrong thing because of ambiguous requirements....not that things like that ever happen in real life!
Whatever tab has "focus" gets compiled when you hit a compile button.
As far as compiling from RAM....
@Roy (correct me if I'm wrong please) seems interested in implementing this feature. Personally, I don't get it and have never thought it was of any value. As long as Roy is willing to do it, and the feature can be fully isolated and encapsulated, it doesn't matter to me if it's there or not.
A top object can be designated in the PropellerTool I use. Compiling top is done with CTRL+F*. This is not Mac compatible though because it uses lots of F keys for system things. I'll make top file compile a future requirement; it won't be in the first cut.
I'll implement it after I'm done with the loader/terminal GUI. :-)
I'd plan to write this separate loader/terminal program using Qt and the terminal program would support Parallax PST emulation as well as VT100/ANSI emulation at the user's choice. The nice thing about having loading and terminal emulation in the same program is that it will reduce or eliminate any delay required before the user's program can produce terminal output.
That would be nice to have. Could it just load any old generic Propeller binary and then present a terminal? That would be really useful for various versions of interpreted type Propeller tools you used like...F.., I mean Basic!
I'm not smart enough to grab any tasks, I'll just build and test and rant.
That would be nice to have. Could it just load any old generic Propeller binary and then present a terminal? That would be really useful for various versions of interpreted type Propeller tools you used like...F.., I mean Basic!
Yes, it will be able to load any Spin binary or PropGCC program. I could make it load Catalina programs as well if I can figure out the Catalina load protocol for XMM programs.
Lately I have been doing a lot of ranting, about Qt5 for Linux, I hope it is not putting off some potential contributors. I can help in the testing of the product, hopefully for Linux(xubuntu) and windows.
A top object can be designated in the PropellerTool I use. Compiling top is done with CTRL+F*. This is not Mac compatible though because it uses lots of F keys for system things. I'll make top file compile a future requirement; it won't be in the first cut.
The Spin Tool does have that feature. I wonder why nobody but Steve knew about it. The "File" menu does include an item to select a top object, which can also be accessed with Ctrl-F. And the "Run" menu does allow you to select the current file or the top object, which can also be access with Ctrl-F8, Ctrl-F10 and Ctrl-F11. There also an F9 option that I've never used, but I should have. I usually do an F8, and then clear the binary display. I'll use F9 in the future.
It's amazing that I never explored these features before. I'm more of a command-line person and don't really use IDE's very effectively.
Hey, if you can make a terminal program that works better and more easily than minicom or gtkterm the world will love you forever!
That isn't really what I'm after. What I actually want to do is write a GUI version of propeller-load. I don't want to write something that tries to compete with existing terminal emulators.
BTW, I just wanted to point out that I deliberately am not interested in having a file/folder listing in the bottom left side panel. It is replaced by a listing of methods which allows clicking on the method name to open it in the editor. This is a first cut requirement, if someone wants to change it they can after the first cut is delivered and tested.
It's likely they are using OGL as a 2D canvas. With a little setup, OGL can do lots of things on a plane, and do so using the GPU or CPU in a cross-platform way. Scrolling, scaling, etc... all make a lot of sense. The guts of it are left to OGL, where falling back to the CPU can happen or not, depending on the platform implementation. Something like Mesa could just use the CPU, should no other support exist. The nice thing about it is basics like clipping, and large render areas can be generated, then moved underneath the canvas window, so scrolling and such happen quickly where there is hardware support. "smooth as glass" kind of thing, where possible.
Without that layer, one must either deal with GPU's more directly (ugly) or make calls to the various window manager / graphics systems in the various OSes (messy, lots of conditionals in the build). Or, make the minimum calls, and just pound the CPU to deal with that canvas old school, bitblit style (power / CPU hungry). On most machines now, that's not a big deal. Some slower devices may well see a power spike on high levels of screen activity, where the GPU would handle it far more efficiently.
My guess anyway...
Re: "It's amazing that I never explored these features before."
Seriously! There is a UX lesson in there somewhere. Discoverability is high with the default tabs and build behavior. I suspect once that is known, people don't go looking past that, unless they feel enough pain to do so, instead just making up a workflow based on the very basic behavior. That's exactly what I did with Prop Tool, never looked back, despite a whole pile of, "it built and loaded, but nothing happened" events caused by having a driver tab open, instead of the top tab... Sheesh!
I'm a big fan of keyboard short cuts too.
Re: Tasks
I'm right in the middle of a job change over. I plan on use testing the IDE, and potentially test building on a couple of platforms, depending on how things shake out. A cross platform Prop Tool type program is of interest to me, mostly because I'm not going to replace my old (ancient now) T60p Lenovo Prop dev machine with another Windows machine. Most likely I'll end up on Mac OS, but I could do Linux too.
Comments
I guess there is the question of what the base program is going to look like before it goes full tilt Spin/PASM? Since this has the potential of working for other compilers, will the actual control of what you want to run be centered on the selection of what goes into the Properties window? Or will the base copy just have that feature? Or something new and different?
As for the name, now I am thinking Ptc, where the P could be interpreted as Propeller or Parallax or Programer or ... , the tc would stand for "tool chain". So the whole thing could be "Ptc Spin inside" or "Ptc (favorite compiler) inside". Or just leave off the "inside" thing.
Now onto the Linux concoction, where do I find an openspin and propeller-load versions that would run in linux? Or how is this to be done?
Ray
Get the openspin source from here: https://code.google.com/p/open-source-spin-compiler/
It compiles very easily on Linux.
For the loader you will find it in the propgcc source code. Check that out from here: https://code.google.com/p/propgcc/source/checkout
You don't need to build or install propgcc but the loader is in the source tree.
David,
I took it the way you did. Whatever tab has "focus" gets compiled when you hit a compile button. It removes the project aspect and lets you have several programs in the works at any one time. Any "project" structure comes solely from the list of objects within a Spin file. I use this feature when playing around with Spin (I don't call what I do developing). I'll often have a null Spin program open in addition to whatever I'm working on. I use it to effectively idle the prop and prevent any mishaps if it gets turned on ....especially good with a robot, just load that program before you put it to bed if what you are working on is mechanically troublesome.
I hadn't even considered the issue Potatohead brought up.
Steve, can you clarify the requirement? It would be terrible to implement the wrong thing because of ambiguous requirements....not that things like that ever happen in real life!
Changing the "\" to "/" solved the problem.
I would think we would want to allow windows users to use 'normal' windows paths instead of forcing users to use the "/" (normal with respect to the windows world).
Chris Wardell
EDIT: Designating the top object could be optional. If a top object isn't identified then the IDE would work just like the Prop Tool does now. That is, F10 and F11 would start compilation from the current file.
Don't they make software packages anymore where at compile time you just choose your target OS? It seems like that would solve a lot of problems and would be very convenient, but I digress.
Ray
I think it is ingrained in the communities and the tools they are used to. If you never had projects and got used to doing things (productively) with multiple "top level" programs open at the same time, then you will have problems adjusting to a project oriented environment....likewise, if you have always had projects in your life and can't imagine just opening up multiple programs and compiling them...well, you will have problems adjusting to the non-structured, no-project world. Neither is better or worse, just different.
I don't think a new, replacement tool for the Propeller Tool can force a project oriented paradigm onto Spin users just because.....I can see the pushback if you are used to just starting to create a Spin program, refer to a few of your favorite objects and start writing code ALL IN ONE FILE and now are being told you need to create a Project file, create your new source file, somehow associated the objects you want to use with the project and then if while working on this you want to create a little stub to test something, you need to open a new instance of the tool and then go through the entire new project process just to try something?
I don't think it is a mistake to give users tools that work how they are used to working.
Before uninstalling 64 bit Qt5 why not just install a 64 bit g++? Surely its only a case of "apt-get install g++". I cannot imagine Ubuntu does not have a compiler. Did they ever make tools like that? Who "they" anyway?
Microsoft for sure has never done that.
The Qt guys have been working on it for years and made a wonderful cross platform tool. It's just very hard what you are asking for is an order of magnitude harder again.
+1
The things people think of when you are typing a rant!!
That's why I like Dave Hein's solution. I think it is the best of both worlds.
@Heater -- Yes! Sublime is well, sublime! The tracking feature is particular nice, because I no longer have to put a window up running tail -f
I'm happy to work either way, and I do plan on getting it all moved over into Sublime, for the features you mentioned, among many others. My points raised really are about new users and how much they have to know to get moving. They can know less and discover more in a more recoverable way with the build from RAM feature. That's my observation having been one and worked with a few in the past. I'm not going to write much about it going forward though.
Seems you and I agree about git and friends. Yes! In the MCAD world, this same problem exists with all the same issues. It's been solved with file based management tools, and users have to understand caches, states, repositories, projects, groups, users, and all manner of other things to work with heirachies of files which form parts, assemblies, drawings and other constructs. It really is a PITA. No MCAD users do it command line. Those tools never did exist, and the binary nature of the files has always prevented git and friends from making too much sense, due to their lack of an ability to parse the binary blobs and pluck out bill of material data, and inter-file geometry references, which is always needed to understand what is what and where and who drives who in the mess of things.
However, there was one really great program that had data management built in. No way to get out of using it. And using that thing was awesome! I taught this material for many years. Still do. And users of that program always had the best time, able to do very complex things, never even worried about a path name! They didn't even have to worry so much about filenames. I've long thought somebody someday would build an IDE that embodies the same basic concept. For newbies, this sort of thing could be awesome. I would help on such a project too. What would happen is this: They would get up to speed managed, and do so very easily. At that point, they would not even imagine working with a mess of files, and would have revisions and such built in to their very basic thought process. Powerful stuff, should it ever happen in this dicipline, IMHO.
In any case, I just wanted to highlight what I've observed about people and how they will tend to work with the build from RAM feature. I don't plan on making a mess of the thread, etc... over it.
I think that at this point I will wait for the next version of the ide code, then I can try this again. Since things will be changing maybe this error will go away.
Ray
A top object can be designated in the PropellerTool I use. Compiling top is done with CTRL+F*. This is not Mac compatible though because it uses lots of F keys for system things. I'll make top file compile a future requirement; it won't be in the first cut.
Thanks CT. I'll look at that. It seems to be handled Ok in SimpleIDE ... I made a change in that area thinking it was superfluous code.
Whatever tab has "focus" gets compiled when you hit a compile button.
As far as compiling from RAM....
@Roy (correct me if I'm wrong please) seems interested in implementing this feature. Personally, I don't get it and have never thought it was of any value. As long as Roy is willing to do it, and the feature can be fully isolated and encapsulated, it doesn't matter to me if it's there or not.
That would be nice to have. Could it just load any old generic Propeller binary and then present a terminal? That would be really useful for various versions of interpreted type Propeller tools you used like...F.., I mean Basic!
I'm not smart enough to grab any tasks, I'll just build and test and rant.
Yet another Ubuntu screw up. What you are missing here is the opengl development libraries.
On my Debian box GL/gl.h is provided by mesa-common-dev and libglu1-mesa-dev both of which are installed.
You can find out what package provides a particular file with the dpkg search option: Also you can find out if a package is installed or not: Note the big and little "s" there.
I'm assuming Ubuntu has not messed things up so much that this does not work for you. The package names may be different of course.
I'm wondering why this IDE needs opengl anyway?
Ray
It's amazing that I never explored these features before. I'm more of a command-line person and don't really use IDE's very effectively.
Hey, if you can make a terminal program that works better and more easily than minicom or gtkterm the world will love you forever!
The Requirements page has been updated.
BTW, I just wanted to point out that I deliberately am not interested in having a file/folder listing in the bottom left side panel. It is replaced by a listing of methods which allows clicking on the method name to open it in the editor. This is a first cut requirement, if someone wants to change it they can after the first cut is delivered and tested.
It's likely they are using OGL as a 2D canvas. With a little setup, OGL can do lots of things on a plane, and do so using the GPU or CPU in a cross-platform way. Scrolling, scaling, etc... all make a lot of sense. The guts of it are left to OGL, where falling back to the CPU can happen or not, depending on the platform implementation. Something like Mesa could just use the CPU, should no other support exist. The nice thing about it is basics like clipping, and large render areas can be generated, then moved underneath the canvas window, so scrolling and such happen quickly where there is hardware support. "smooth as glass" kind of thing, where possible.
Without that layer, one must either deal with GPU's more directly (ugly) or make calls to the various window manager / graphics systems in the various OSes (messy, lots of conditionals in the build). Or, make the minimum calls, and just pound the CPU to deal with that canvas old school, bitblit style (power / CPU hungry). On most machines now, that's not a big deal. Some slower devices may well see a power spike on high levels of screen activity, where the GPU would handle it far more efficiently.
My guess anyway...
Re: "It's amazing that I never explored these features before."
Seriously! There is a UX lesson in there somewhere. Discoverability is high with the default tabs and build behavior. I suspect once that is known, people don't go looking past that, unless they feel enough pain to do so, instead just making up a workflow based on the very basic behavior. That's exactly what I did with Prop Tool, never looked back, despite a whole pile of, "it built and loaded, but nothing happened" events caused by having a driver tab open, instead of the top tab... Sheesh!
I'm a big fan of keyboard short cuts too.
Re: Tasks
I'm right in the middle of a job change over. I plan on use testing the IDE, and potentially test building on a couple of platforms, depending on how things shake out. A cross platform Prop Tool type program is of interest to me, mostly because I'm not going to replace my old (ancient now) T60p Lenovo Prop dev machine with another Windows machine. Most likely I'll end up on Mac OS, but I could do Linux too.
potatohead, Perhaps that is a new feature of Qt4. Never was so before.
But if that is so why would application code need to know about it and include gl.h?
I have to download this and check it out...