I know that everyone is getting the simulator to work. I normally don't work with the command prompt and I am having a little brain fart:blank:. I am wondering if someone point me in right why with the command prompt commands and know its like ridding a bike,but I seem to have fallen off.
Type: spinsim [-l] file
where file is binary you have compiled with spin compiler (proptool/bst/homespun/..), e.g spinsim demo.binary
Using #include <sys/types.h> is fine for picking up uint16_t etc... (and lots of other types) with several compilers. ANSI C99 defines stdint.h C89 does not specify either file AFAIK.
I know that everyone is getting the simulator to work. I normally don't work with the command prompt and I am having a little brain fart:blank:. I am wondering if someone point me in right why with the command prompt commands and know its like ridding a bike,but I seem to have fallen off.
@bsnut,
First you need a command window. In Windows XP and Vista, you can click Start then Run and type "cmd" in the dialog box to get a DOS command window. In Windows 7 click Start then Help and find the Run topic.
Next you need to be in the folder where you downloaded and unpacked your .zip package. Typically the DOS command window will put you into your home folder. From there if you unpacked your .zip to "My Documents", then use cd "My Documents\spinsim013" If you unpacked your .zip to C: drive, you can use cd C:\spinsim013
After you get to the path, you can run the spinsim program like this: spinsim hello.binary
Start the demo program as: spinsim demo.binary . The demo output looks like this:
Avaliable Commands
help - Print the available commands
dump file - Dump the contents of a file in hex
type file - Print the contents of a file
run file - Load and run Spin binary file in a new cog
run0 file - Load and run Spin binary file in the current cog
dir - Directory listing
exit - Exit the program
>
@rosco_pc, I got spinsim to work on the linux machine at work using the changes you suggested. The regs[32] array is no longer being used, and I'll remove that in the next version.
@jazzed, I added #include <sys/types.h> to interp.h and changed BYTE, WORD and LONG to use uint8_t, uint16_t and int32_t. That's works great for both linux and Windows. I'll make those changes for the next version also.
@bsnut, I hope to make a Windows version of spinsim in the near future, but in the mean time you will have to run it in a DOS window. Hopefully, the instructions that jazzed posted will solve your problems.
@jazzed, I added #include <sys/types.h> to interp.h and changed BYTE, WORD and LONG to use uint8_t, uint16_t and int32_t. That's works great for both linux and Windows. I'll make those changes for the next version also.
That caught my eye too. Without diffs it's hard to tell though. I assume Dave has a good reason or it's a type-o. I speculate that it has to do with how spin handles negative numbers and int32_t makes more sense as 32 bits is the default data type (size_t). Byte and word types in spin can be negative too, but that's less common.
Hey Dave, when you gonna add a PASM simulator? I'd like to run all kinds of Spin/PASM programs on my desktop. I know Gear can do PASM, but I don't understand Gear at all !
Spin treats 32-bit longs as signed, so it seems like int32_t is a better choice. I do cast the signed value to unsigned when doing a right-shift, but everything else is done with signed 32 bit values. Byte and word values are normally unsigned unless the ~ or ~~ sign extension operators are used. It really only matters for a few operators, such as <, >, =<, =>, *, **, /, // <#, #>, and ~>. OK, so it's more than a few operators. Sign doesn't matter for the other operators.
A PASM interpreter should be a bit easier to implement than the spin interpreter. PASM is well documented, and I have already implemented most of the operators in the spin interpreter. I'll have to try out GEAR first to see how that works.
GEAR is not a simulator,but an emulator and aims at emulating a complete Propeller (including all IO/Video Generators/Counters) following precise timing. This slows things down a bit.
And like Jazzed I do not really understand how to use GEAR.
I downloaded GEAR and looked at the source code. The version I downloaded was from October of 2009. I don't know if there's a later version or not. I started up GEAR on my PC, but I didn't spend much time trying to figure out how to run anything, so I didn't actually run a simulation.
It appears that GEAR implements a cycle-accurate simulation of the Prop. As rosco_pc said, it supports pin I/O, video generators and counters. It also accounts for HUB access timing when a cog accesses the HUB. From what I can tell, it also seems to implement a spin interpreter that is not cycle-accurate, which is similar to the approach I took. There are a few spin bytecodes that were not implemented in GEAR, but support for these may have been added later on.
My approach for spinsim is a bit different. My goal is to develop a virtual machine that can run spin bytecodes on other platforms, such as Windows and linux machines. This makes it possible to develop and test spin programs on a Windows or linux platform without running it on a physical propeller chip. Much of the development work can be done within the development platform, and then loaded onto a physical chip later in the development cycle.
The other aspect of spinsim is that it allows for the spin language to be used on other platforms than just the prop chip. This might be useful in the educational field where spin could be taught as another programming language, independent of the propeller. There could be a large-memory version of the spin binary and interpreter that uses long memory pointers instead of word pointers in the method table and stack frame. That way, spin programs could access mega-bytes of memory instead of just 64K.
I have attached an updated version of SpinSim that includes a PASM simulator and more file I/O functions. I also spent some time cleaning up the linux implementation and getting the file I/O routines to work properly under linux.
I added an extra option, -p, which uses the PASM spin interpreter in ROM instead of the normal spin intepreter. The normal spin interpreter will be used if the -p option is not specified.
The only drawback so far between running on a real propeller and the simulation appears to be the need to replace the serial (FullDuplexSerial or whatever) object with conio.spin. I guess a different library path could be used for conio.spin assuming real serial port routines.
I'm running a complicated BMA debug session on the simulator and the only difference i've seen in the execution so far is the number of cogs in use.
In theory, the simulator could interface to serial I/O drivers by monitoring the I/O pins. It would require better resolution on the CNT registers than the 1 msec resolution I currently have. That should be easy to do on linux, but I'm not sure how to do it under Windows.
I tried out the BMA debugger on the simulator. I renamed a copy of conio.spin to FullDuplexSingleton.spin, and I added an rxready method to it. Eventually, conio will have most of the methods provided by the serial drivers that are generally used so that it can be a drop in replacement for them.
The debugger has some nice features. It would be good to incorporate some of them into SpinSim at some point.
I ended up using a flag for the building the simulator version -D SPINSIM selects conio.
One thing I noticed while debugging a PASM program is that the program quits if input does not come after some time. I changed the while to for(; runflag; ++loopcount) for the time being.
Also looks like kbhit could provide the O/S a little breathing room. I added select(0,0,0,0,&tv) with tv.tv_sec = 0; and tv.tv_usec = 1000; for a 1ms delay and it's much better.
I'd like to see BMA be a little easier to use with watch variables for example - I have a GUI for it, but haven't looked at that much lately.
The default value for maxloop is 2 billion. I didn't think that the simulator would need to run for more than a few minutes, and I thought 2 billion loops would be more than enough. However, that's only about 800 seconds on my PC, and it would be even less on higher speed machines. Running more cogs and checking kbhit periodically will slow the simulator down, and it would run longer. I'll change the loop logic so it doesn't terminate unless all the cogs are stopped or the user specifies a loop limit.
I uploaded SpinSim version 0.21 and attached it to the first post in this thread. I fixed a few bugs and added a couple of features as listed below.
- Now use ROL instead of SHL for the ldlip opcode to match the ROM interpreter
- Fixed the increment/decrement mask for long values
- Implemented the swap-parameter feature for the math ops
- Fixed a problem when dividing by zero
- Fixed a problem with coginit and cogstop of the current cog so it doesn't write location zero
- Added better profiling for the extra ops
- Added a -m option to specify larger memory sizes
I have not read this thread, however I was wondering how your project was coming along. You mentioned that you were making some headway in this project. I was wondering how you made the breakthrough.
I haven't integrated SpinSim with the Windows app yet, but I do have a simple Windows app that works. The simple app uses a timer that triggers 100 times/second. My plan is to run a few thousand cycles in the simulator and then return back to the Windows message loop to check for messages.
I sent you a PM about it, but you may not have received it. Thanks for your help on programming with Windows. The Microsoft site provides a lot of useful information.
Sorry. I did receive that PM but I forgot about it.
The Microsoft site provides a lot of useful information
Yes it does. When I was younger, I would spend about 16 hours a day there. There are a lot of useful examples there that can be used in almost any type of programming.
Okay, it is just a suggestion, but I would recommend at least checking out the free trial version. I think if you get the hang of it, MFC will make it a whole lot easier to program for the Windows OS.
Please, please, if anyone has the inclination, skill, time, altruism and generosity to create and donate to the community nice shiny graphical user interface apps for use with the Propeller (or anything else for that matter) could they please consider using a cross-platform GUI tool kit rather than a OS specific tool kit.
This has the following benefits for the user community you are creating for:
1) Users with different operating systems can enjoy the fruits of your labour.
2) There will be more users who can help and contribute to the effort.
3) The finished program will be usable on different architectures, say the coming generations of ARM devices from tablets to net books etc.
4) Users will not be dependent on closed source tools and onerous licensing in order to use the program.
Given that sometimes we like to create programs with the view of donating them to the world it makes sense to me to ensure that no one "out there" is left out due to the fact that he languages and libraries used in the program are not available to them.
As a practical matter such cross platform apps can be created with Qt, for example, and I'm sure the effort involved is no greater than using a more limited system. The results are just as good looking.
I've been searching just tonight for a "universal" program that will run on multiple platforms. It seems the answer is to go back in time. I have a console program running on a PC running C89, and I have exactly the same program running on a propeller, also running in C89. I very much suspect the same program would run on Linux as well.
But of course that is a text program. You are talking of a GUI. I wonder what a "hello world" is for a GUI? Maybe a button that you press and then a text box changes its text and says "Hello World". What language do you write this in? Do GUIs exist on multiple platforms that would look similar and at least run the same code?
I see that Qt is not free:
For example:
One Developer License
Qt Desktop Single Operating System
$3 695
Do GUIs exist on multiple platforms that would look similar and at least run the same code?
That is a wonderful case of wishful thinking.
In order to achieve a GUI within a reasonable amount of time and with a reasonable amount of effort, a programmer must make choices as to which platforms he intends to support. That being said, I wish you success with your project Heater.
As you see Qt uses C++. The same code can be compiled to run on Windows, Linux, BSD, various ARM boards with Linux, or even on you mobile phone (Symbian or Nokia N900 for example)
Yes, I would hope that command line programs written in a standard C dialect will run anywhere. But even then you can find your self with, for example, serial port handling code that is OS dependent.
Even there things like Qt come to rescue for portability as you can write non-GUI, command line, apps as well but still make use of all those other OS abstractions.
Qt has been available for free for a long time. After all it is what is used to create the KDE desktop and applications under Linux etc.
Specifically it is available under the Lesser General Public Licence which means that you can use it for free. You can distribute your works in closed or open source form.
That expensive licence is the commercial option which perhaps buys you some support and enables you to link Qt statically to your program and redistribute without source.
Looking at the kind of thing you have been doing we see that Qt could be a great help with its text edit component which is very easily configurable for any syntax highlighting. Ther eis an ocean of other useful stuff in Qt.
It has been possible to write very portable cross-platform GUI apps for a long time now.
Take a look at BradC's BST Spin IDE and compiler as a fine example. It is a very decent cross-platform GUI app that runs on Linux, Windows and Mac. It could easily be compiled to run on BSD and Brad has said he is prepared to build a version for the ARM architecture when the demand comes. I believe Brad uses the wxWidgets tool kit http://www.wxwidgets.org/
In order to achieve a GUI within a reasonable amount of time and with a reasonable amount of effort, a programmer must make choices as to which platforms he intends to support
As I say, not true any more. In my professional life I have just spend a year or more developing one major and some minor GUI apps using Qt. I do all my development under Linux. Just recently we started to deliver these apps to our users who, inevitably, are all using Windows. No problem, fire up a Windows machine, install the Windows version of the IDE load the project and hit the build button. In no time we have Windows builds running.
I have to admit that a colleague who develops on Windows had a harder time getting his code to work on Linux. Windows coders just can't resist putting in those Windows dependancies for no apparent reason:) They are just not used to this new fangled cross-platform idea.
idbruce,
That being said, I wish you success with your project Heater.
Thank you. We are going to need luck and a lot of hard work with those apps. No matter how good Qt is.
Perhaps I should clarify my position a little. I know there has been a lot of people doing cross platform programming since I started many years ago. However, much of the complexity will be dependant upon the bells and whistles. I am sure that many apps can be written to operate on many platforms. I am a bells and whistle type of programmer. I like providing many options in my apps that would be very difficult to cross platform, or it would take an extraordinary amount of time to complete such a project. Hence the previous comment.
reasonable amount of time and with a reasonable amount of effort
I would be interested to hear examples of the bells and whistles you have in mind. Perhaps I'm missing something important.
I have to say I'm overjoyed if I get can an app out with all the requirements met, let alone any extras:)
So far, perhaps luckily, our users have not been requesting features like that that can't be implemented in a cross-platform manner.
Now, my thesis still stands:
If one is wanting to share the fruits of ones labours with a wide community of diverse users, perhaps out of altruism, perhaps just for the need to show off, perhaps, more importantly, with the hope that others will join in and help move the project forward in areas where ones own skill or available time are lacking. If that is what one wants to do, then it makes sense to create cross-platform and reach the widest audience.
If that means sacrificing a unessential few bells and whistles it is a good trade off.
In a previous discussion, you and I were discussing dialog boxes. As I mentioned, dialog boxes can be used as full blown Window applications.
Many years ago, I tried to get my foot in the door of Harley Davidson with my programming efforts. I created a full blown dialog box application which embraced the Harley Davidson emblem, the mindset, etc....
Upon execution, this application used "regions" for two instances:
The initial splash screen was the Harley emblem embedded on the chest of an eagle. There was no square frame (window) around the eagle, the contour followed the wings of the eagle. Within the Harley emblem (based on a timer) the latest Harley editions changed showing all the new models. While the new models were being displayed, you heard the roaring sound of a Harley in the background and then doing a burn-out as the last models were being displayed. As the splash screen exited, the main dialog box app appeared, which is described below.
The main dialog box app was was simply the HD logo on a windows desktop with no square frame (window) around the logo, the contour followed the HD logo. It was just like the logo was embedded on the desktop. If you left clicked the logo, it would then disappear to the system tray area, and if right clicked the logo, it would display a menu with user options.
The first two examples would be very hard to cross platform, and that does not include the rest of the program. It all depends on what you want to accomplish and how you want to accomplish it. If you are just looking for a few pushbuttons for user input, I am sure that would be a lot easier than an application that allows you to change fonts, print documents, display bitmaps, etc....
You are the creator and it is your canvas, paint whatever picture you desire
Well yes, there are limits, if your underlying operating system/window system does not support some features then you just can't do it. 3D accelerated graphics would be a an example, if your hardware has no acceleration it's not going to be much fun.
However, shaped widgets as you describe is dead easy under Qt for all platforms, widgets as full windows as you say. See this example in the Qt reference documentation. It's only a round clock as an example but any irregular shape is equally easy. http://doc.qt.nokia.com/latest/widgets-shapedclock.html
As a splash screen is just a widget it would be easy to create your own much the same way.
Playing sounds in Qt is also a synch.
Changing font's, printing documents, displaying bit maps, SVG diagrams, 3D graphics with OpenGL is all relatively painless in Qt.
One thing that looks tricky to me in Qt is "disappear to the system tray area". But that is done on Linux desk tops with Qt all the time.
You are the creator and it is your canvas, paint whatever picture you desire
I like that, luckily I have been allowed a lot of free reign on the canvas with the apps I have mentioned above.
If you target a specific OS, your application should be substantially easier to create.
I learned a long time ago, that I can't please everyone, and I guess I think of my apps in the same way. I am very one-sided when it comes to computers and GUI. I like Windows, however, I realize many people don't like Windows. In which case, my software is not for them, because I was the painter and it was my canvass, and I chose Windows.
But just in case.... I am not bashing other OS's, Windows is just MY personal preference. I am not saying it is for everyone.
Comments
Type: spinsim [-l] file
where file is binary you have compiled with spin compiler (proptool/bst/homespun/..), e.g spinsim demo.binary
Using #include <sys/types.h> is fine for picking up uint16_t etc... (and lots of other types) with several compilers. ANSI C99 defines stdint.h C89 does not specify either file AFAIK.
@bsnut,
First you need a command window. In Windows XP and Vista, you can click Start then Run and type "cmd" in the dialog box to get a DOS command window. In Windows 7 click Start then Help and find the Run topic.
Next you need to be in the folder where you downloaded and unpacked your .zip package. Typically the DOS command window will put you into your home folder. From there if you unpacked your .zip to "My Documents", then use cd "My Documents\spinsim013" If you unpacked your .zip to C: drive, you can use cd C:\spinsim013
After you get to the path, you can run the spinsim program like this: spinsim hello.binary
Start the demo program as: spinsim demo.binary . The demo output looks like this:
Hope that helps.
@jazzed, I added #include <sys/types.h> to interp.h and changed BYTE, WORD and LONG to use uint8_t, uint16_t and int32_t. That's works great for both linux and Windows. I'll make those changes for the next version also.
@bsnut, I hope to make a Windows version of spinsim in the near future, but in the mean time you will have to run it in a DOS window. Hopefully, the instructions that jazzed posted will solve your problems.
Shouldn't LONG be changed to uint32_t?
That caught my eye too. Without diffs it's hard to tell though. I assume Dave has a good reason or it's a type-o. I speculate that it has to do with how spin handles negative numbers and int32_t makes more sense as 32 bits is the default data type (size_t). Byte and word types in spin can be negative too, but that's less common.
Hey Dave, when you gonna add a PASM simulator? I'd like to run all kinds of Spin/PASM programs on my desktop. I know Gear can do PASM, but I don't understand Gear at all !
A PASM interpreter should be a bit easier to implement than the spin interpreter. PASM is well documented, and I have already implemented most of the operators in the spin interpreter. I'll have to try out GEAR first to see how that works.
And like Jazzed I do not really understand how to use GEAR.
It appears that GEAR implements a cycle-accurate simulation of the Prop. As rosco_pc said, it supports pin I/O, video generators and counters. It also accounts for HUB access timing when a cog accesses the HUB. From what I can tell, it also seems to implement a spin interpreter that is not cycle-accurate, which is similar to the approach I took. There are a few spin bytecodes that were not implemented in GEAR, but support for these may have been added later on.
My approach for spinsim is a bit different. My goal is to develop a virtual machine that can run spin bytecodes on other platforms, such as Windows and linux machines. This makes it possible to develop and test spin programs on a Windows or linux platform without running it on a physical propeller chip. Much of the development work can be done within the development platform, and then loaded onto a physical chip later in the development cycle.
The other aspect of spinsim is that it allows for the spin language to be used on other platforms than just the prop chip. This might be useful in the educational field where spin could be taught as another programming language, independent of the propeller. There could be a large-memory version of the spin binary and interpreter that uses long memory pointers instead of word pointers in the method table and stack frame. That way, spin programs could access mega-bytes of memory instead of just 64K.
I added an extra option, -p, which uses the PASM spin interpreter in ROM instead of the normal spin intepreter. The normal spin interpreter will be used if the -p option is not specified.
The only drawback so far between running on a real propeller and the simulation appears to be the need to replace the serial (FullDuplexSerial or whatever) object with conio.spin. I guess a different library path could be used for conio.spin assuming real serial port routines.
I'm running a complicated BMA debug session on the simulator and the only difference i've seen in the execution so far is the number of cogs in use.
I tried out the BMA debugger on the simulator. I renamed a copy of conio.spin to FullDuplexSingleton.spin, and I added an rxready method to it. Eventually, conio will have most of the methods provided by the serial drivers that are generally used so that it can be a drop in replacement for them.
The debugger has some nice features. It would be good to incorporate some of them into SpinSim at some point.
One thing I noticed while debugging a PASM program is that the program quits if input does not come after some time. I changed the while to for(; runflag; ++loopcount) for the time being.
Also looks like kbhit could provide the O/S a little breathing room. I added select(0,0,0,0,&tv) with tv.tv_sec = 0; and tv.tv_usec = 1000; for a 1ms delay and it's much better.
I'd like to see BMA be a little easier to use with watch variables for example - I have a GUI for it, but haven't looked at that much lately.
I'll upload a new version soon.
- Now use ROL instead of SHL for the ldlip opcode to match the ROM interpreter
- Fixed the increment/decrement mask for long values
- Implemented the swap-parameter feature for the math ops
- Fixed a problem when dividing by zero
- Fixed a problem with coginit and cogstop of the current cog so it doesn't write location zero
- Added better profiling for the extra ops
- Added a -m option to specify larger memory sizes
I have not read this thread, however I was wondering how your project was coming along. You mentioned that you were making some headway in this project. I was wondering how you made the breakthrough.
Bruce
I haven't integrated SpinSim with the Windows app yet, but I do have a simple Windows app that works. The simple app uses a timer that triggers 100 times/second. My plan is to run a few thousand cycles in the simulator and then return back to the Windows message loop to check for messages.
I sent you a PM about it, but you may not have received it. Thanks for your help on programming with Windows. The Microsoft site provides a lot of useful information.
Dave
Sorry. I did receive that PM but I forgot about it.
Yes it does. When I was younger, I would spend about 16 hours a day there. There are a lot of useful examples there that can be used in almost any type of programming.
Did you download a trial version?
Bruce
Okay, it is just a suggestion, but I would recommend at least checking out the free trial version. I think if you get the hang of it, MFC will make it a whole lot easier to program for the Windows OS.
Bruce
This has the following benefits for the user community you are creating for:
1) Users with different operating systems can enjoy the fruits of your labour.
2) There will be more users who can help and contribute to the effort.
3) The finished program will be usable on different architectures, say the coming generations of ARM devices from tablets to net books etc.
4) Users will not be dependent on closed source tools and onerous licensing in order to use the program.
Given that sometimes we like to create programs with the view of donating them to the world it makes sense to me to ensure that no one "out there" is left out due to the fact that he languages and libraries used in the program are not available to them.
As a practical matter such cross platform apps can be created with Qt, for example, and I'm sure the effort involved is no greater than using a more limited system. The results are just as good looking.
I've been searching just tonight for a "universal" program that will run on multiple platforms. It seems the answer is to go back in time. I have a console program running on a PC running C89, and I have exactly the same program running on a propeller, also running in C89. I very much suspect the same program would run on Linux as well.
But of course that is a text program. You are talking of a GUI. I wonder what a "hello world" is for a GUI? Maybe a button that you press and then a text box changes its text and says "Hello World". What language do you write this in? Do GUIs exist on multiple platforms that would look similar and at least run the same code?
I see that Qt is not free:
That is a wonderful case of wishful thinking.
In order to achieve a GUI within a reasonable amount of time and with a reasonable amount of effort, a programmer must make choices as to which platforms he intends to support. That being said, I wish you success with your project Heater.
Bruce
Recently I have been using Qt, you can get GUI apps up very quickly with it. Here is hello word for Qt:
#include <QApplication> #include <QPushButton> int main(int argc, char *argv[]) { QApplication app(argc, argv); QPushButton hello("Hello world!"); hello.show(); return app.exec(); }As you see Qt uses C++. The same code can be compiled to run on Windows, Linux, BSD, various ARM boards with Linux, or even on you mobile phone (Symbian or Nokia N900 for example)
Yes, I would hope that command line programs written in a standard C dialect will run anywhere. But even then you can find your self with, for example, serial port handling code that is OS dependent.
Even there things like Qt come to rescue for portability as you can write non-GUI, command line, apps as well but still make use of all those other OS abstractions.
Qt has been available for free for a long time. After all it is what is used to create the KDE desktop and applications under Linux etc.
Specifically it is available under the Lesser General Public Licence which means that you can use it for free. You can distribute your works in closed or open source form.
That expensive licence is the commercial option which perhaps buys you some support and enables you to link Qt statically to your program and redistribute without source.
Looking at the kind of thing you have been doing we see that Qt could be a great help with its text edit component which is very easily configurable for any syntax highlighting. Ther eis an ocean of other useful stuff in Qt.
That is most certainly not true.
It has been possible to write very portable cross-platform GUI apps for a long time now.
Take a look at BradC's BST Spin IDE and compiler as a fine example. It is a very decent cross-platform GUI app that runs on Linux, Windows and Mac. It could easily be compiled to run on BSD and Brad has said he is prepared to build a version for the ARM architecture when the demand comes. I believe Brad uses the wxWidgets tool kit http://www.wxwidgets.org/ As I say, not true any more. In my professional life I have just spend a year or more developing one major and some minor GUI apps using Qt. I do all my development under Linux. Just recently we started to deliver these apps to our users who, inevitably, are all using Windows. No problem, fire up a Windows machine, install the Windows version of the IDE load the project and hit the build button. In no time we have Windows builds running.
I have to admit that a colleague who develops on Windows had a harder time getting his code to work on Linux. Windows coders just can't resist putting in those Windows dependancies for no apparent reason:) They are just not used to this new fangled cross-platform idea.
idbruce,
Thank you. We are going to need luck and a lot of hard work with those apps. No matter how good Qt is.
Everyone,
There is a Qt tutorial here: http://doc.qt.nokia.com/4.4/tutorials-tutorial-t1.html
You can get the free LGPL'ed Qt libraries and SDK here: http://qt.nokia.com/downloads/
You will see that he IDE is very sophisticated and is itself a fine example of cross-platform programming.
Perhaps I should clarify my position a little. I know there has been a lot of people doing cross platform programming since I started many years ago. However, much of the complexity will be dependant upon the bells and whistles. I am sure that many apps can be written to operate on many platforms. I am a bells and whistle type of programmer. I like providing many options in my apps that would be very difficult to cross platform, or it would take an extraordinary amount of time to complete such a project. Hence the previous comment.
But like I said, good luck with it.
Bruce
I would be interested to hear examples of the bells and whistles you have in mind. Perhaps I'm missing something important.
I have to say I'm overjoyed if I get can an app out with all the requirements met, let alone any extras:)
So far, perhaps luckily, our users have not been requesting features like that that can't be implemented in a cross-platform manner.
Now, my thesis still stands:
If one is wanting to share the fruits of ones labours with a wide community of diverse users, perhaps out of altruism, perhaps just for the need to show off, perhaps, more importantly, with the hope that others will join in and help move the project forward in areas where ones own skill or available time are lacking. If that is what one wants to do, then it makes sense to create cross-platform and reach the widest audience.
If that means sacrificing a unessential few bells and whistles it is a good trade off.
This is just one example.
In a previous discussion, you and I were discussing dialog boxes. As I mentioned, dialog boxes can be used as full blown Window applications.
Many years ago, I tried to get my foot in the door of Harley Davidson with my programming efforts. I created a full blown dialog box application which embraced the Harley Davidson emblem, the mindset, etc....
Upon execution, this application used "regions" for two instances:
- The initial splash screen was the Harley emblem embedded on the chest of an eagle. There was no square frame (window) around the eagle, the contour followed the wings of the eagle. Within the Harley emblem (based on a timer) the latest Harley editions changed showing all the new models. While the new models were being displayed, you heard the roaring sound of a Harley in the background and then doing a burn-out as the last models were being displayed. As the splash screen exited, the main dialog box app appeared, which is described below.
- The main dialog box app was was simply the HD logo on a windows desktop with no square frame (window) around the logo, the contour followed the HD logo. It was just like the logo was embedded on the desktop. If you left clicked the logo, it would then disappear to the system tray area, and if right clicked the logo, it would display a menu with user options.
The first two examples would be very hard to cross platform, and that does not include the rest of the program. It all depends on what you want to accomplish and how you want to accomplish it. If you are just looking for a few pushbuttons for user input, I am sure that would be a lot easier than an application that allows you to change fonts, print documents, display bitmaps, etc....You are the creator and it is your canvas, paint whatever picture you desire
Bruce
Well yes, there are limits, if your underlying operating system/window system does not support some features then you just can't do it. 3D accelerated graphics would be a an example, if your hardware has no acceleration it's not going to be much fun.
However, shaped widgets as you describe is dead easy under Qt for all platforms, widgets as full windows as you say. See this example in the Qt reference documentation. It's only a round clock as an example but any irregular shape is equally easy. http://doc.qt.nokia.com/latest/widgets-shapedclock.html
As a splash screen is just a widget it would be easy to create your own much the same way.
Playing sounds in Qt is also a synch.
Changing font's, printing documents, displaying bit maps, SVG diagrams, 3D graphics with OpenGL is all relatively painless in Qt.
One thing that looks tricky to me in Qt is "disappear to the system tray area". But that is done on Linux desk tops with Qt all the time.
I like that, luckily I have been allowed a lot of free reign on the canvas with the apps I have mentioned above.
I guess what I am trying to say is this....
If you target a specific OS, your application should be substantially easier to create.
I learned a long time ago, that I can't please everyone, and I guess I think of my apps in the same way. I am very one-sided when it comes to computers and GUI. I like Windows, however, I realize many people don't like Windows. In which case, my software is not for them, because I was the painter and it was my canvass, and I chose Windows.
But just in case.... I am not bashing other OS's, Windows is just MY personal preference. I am not saying it is for everyone.
Bruce