I'm trying to find a modern environment similar to what I found great about QBasic but making up for the flaws. The purpose of this is to code with my 6 year old son.
I'm looking for an IDE that uses a modern language, has the ability to draw graphics and play audio, and doesn't force the User to jump around much between coding and running their application.
In QBasic you had basically two modes: Edit and Run. There were no third party libraries required for creating graphics or generating Audio tones (that I remember). You never had more than one "window" opened at a time.
Is there a modern day equivalent IDE which uses a modern language that provides what I'm looking for?
I don't want him to have to jump around between various windows, try to wrap his mind around window toolkits, understand the command line, or use OOP just to get started. My end goal is to create simple graphical games with him -- not printing text out to the console.
(Preferably cross platform or useable on Mac OSX since that's what we have at the house. Preferably Python based since that's my language of choice.)
QBasic is a great option. You can purchase an old PC from a thrift store and run QBasic on it. There is the option of QB64 which can run on both Mac and Windows. Hope this is helpful.
I'd suggest QB64, almost 100% compatible with QBasic/QuickBasic but runs on Windows.
You could maybe try Small Basic, it aimed to recreate the ease-of-use and educational purposes of the old BASIC languages build into home computers from the 1980s
The Small Basic project was initiated following this article on Salon:
Why Johnny can’t code (David Brin, 2006)
I have a basic firmware question. I am looking to program a nRF51822 IC and integrate it on my own PCB. The evaluation kit seems to already have the IC soldered on it. Is it a way I can only program the nRF51822 and getting it ready to use elsewhere?
Get yourself one of these J-LINK LITE CortexM:
and hook up your connection header like this to your microcontroller (SWDIO, SWCLK, VCC and GND are the only ones needed):
.
Then, use Keil or nRFGo Studio to program your device.
You don't need J-Link at all. Any STLinkv2 board will work, like STM32 dev boards. But even nicer are these cheap Chinese programmers: http://www.aliexpress.com/item/FREE-SHIPPING-ST-Link-V2-stlink-mini-STM8STM32-STLINK-simulator-download-programming-With-Cover/32247200104.html
All you need to do is connect the Vcc, Ground, SDIO, and SWDCLK lines from your board/chip to the programmer, so make sure those pins are broken out and easy to get to.
There are some good instructions on how to do that here: https://github.com/RIOT-OS/RIOT/wiki/Board:-yunjia-nrf51822
I've built Linux workstations for workers on assembly lines to use with this method, and it just loops over and over for new boards. So they don't even need to touch the PC, they can just place a board on the jig or connect a header and it's all automatic.
You will need a programming device, such as a Segger Jlink. The eval kit has an on-board Segger programmer on it (that big chip with the Segger sticker on it).
I'm working through this process myself at the moment. I read somewhere that some people were successful at 'hacking' the eval kit, to bring the SWDIO and SWCLK over to their custom board but that really isn't the right way to go about it.
Instead, purchase an actual programmer and put a programming header on your custom circuit board.
While I am also still in the research phase here as well, it looks like there are 4-5 pins to connect from the programmer to your custom target board. The nRF documentation seems to be rather lacking in the definition of the programming setup, but look under the debugging category and take a look at Segger documentation as well.
If going into mass production there are ways to pre-program the chip before assembly, but I haven't had a chance to learn about that just yet.
I was wondering how i would be able to get started with controlling my nikon DSLR camera? I have been reading on the Nikon SDK and MPT/PTP and is really confused on how to start with writing a script to control it. Thanks for helping me.
If you are just wanting to script stuff, under Linux libgphoto2 and gphoto2 are a good start.
You can use them under windows, I'm not sure if there are pre-compiled build available, but that would also require installing the USB wrapper libraries, and that a touch fiddly.
The next step above that is to compile libgphoto2 in cygwin (there are some good guides how to this on the web), but that overkill.
I am currently using digicamcontrol in windows, and for Nikon and C# code it's really nice to use, and very fast, plus it has no hassle on the USB front. It wouldn't be too hard to write a small C# that does what you want (unknown) and then run that from scripts.
this is what you are looking for:
http://sourceforge.net/projects/nikoncswrapper/
Good luck
In case anybody is still looking at this: the answer is a bit more complex if what you are looking to do is write your own code to access a Nikon DSLR. Thomas Dideriksen's SDK wrapper referenced above is great in making it easy to access Nikon's SDK to control almost all camera functions - but it is restricted to USB-cable access since that SDK does not support wireless access. If the latter is what you want, your best option may be Duka Istvan's digiCamControl, which Simeon suggests above. This open-source C# project can be used as a standalone library. (See the development documentation page.) It is not all that well documented, though, so figuring out how to control all camera parameters can be tricky.
i want to make an action game where the player is in a maze and while escaping he has to kill other player / monsters. The game will be available on Windows.
I don't know where to start.
I looked at C++ and DirectX9 but it's a little bit hard for me, XNA for C# is not supported anymore by Microsoft, GameMaker 8 Pro doesn't seems so complete.
Maybe a book to read will be good, hope in your answers.
Just to give you a kickstart, i'd recommend you to take a look at visual C# and openTK, maybe JitterPhysics
http://www.opentk.com/
http://jitter-physics.com/wordpress/
depending on your programming knowledge this could be all you need to start.
Also its allways a good idea to look at how other engines solve problems, for instance download the free version of unity and look at a view abstractions they make.
I've been developing for Windows and *nix platforms for quite some time, and am looking to move into Mac development. I am tossing up between using ObjC/Cocoa and C++/Qt4.5.
The C++/moc semantics make more sense to me, and improving knowledge in Qt seems like a sensible thing to do given that you end up with a skill set that covers more platforms.
Am I likely to handicap my applications by skipping Cocoa?
The sample Qt applications look pretty Mac-native to me, but they are quite simple so potentially don't tell the whole story. Are there other pros to the Xcode way that Qt doesn't have, such as packaging, deployment, etc.?
Here's an easy way to answer it:
If you were developing a Windows app with .NET or MFC, would you handicap your applications by using Qt? If the answer to that is yes, then the situation is likely to be the same on the Mac.
A few negatives I can think of off the top of my head:
Licensing
Qt apps, while good, are not completely a native UI experience and there's things a native UI designer can do in Cocoa which boggle the mind. While I can't be sure that all the same functionality isn't available in Qt, I doubt it.
Qt is always a little behind. If Microsoft or Apple come out with a great new technology, you have to wait for the Qt developers to update Qt.
However, with all that said, only you can determine the business value of using Qt. If you think cross-platform development is going to be a major part of your development, then Qt might be worth it, despite the issues mentioned.
Ask yourself: how many of the best Mac applications that you know of use Qt instead of native Cocoa?
For our robotic systems, we originally wrote our control software in C++ using the cross-platform wxWidgets library (we avoided Qt due to some licensing concerns), because we felt that we had to target Windows, Linux, and Mac platforms for our end users. This is what we shipped for over a year until I started tinkering with Cocoa.
Right away, the thing that most impressed me was how quickly you could develop using Cocoa. Eventually, we decided to drop support for Linux and Windows and rewrite our entire control applications in Cocoa. What had taken us years to put together in C++ required only three months to completely reimplement in Cocoa.
Aside from the "lowest common denominator" interface issues that others have pointed out, the rapid development allowed by Cocoa has become a competitive advantage for our company. Our software has advanced far more quickly since our conversion to Cocoa, and it has allowed us as a new company with one developer to pull even with 10-year-old competitors that have 20-man development teams. This appears to be a common story in the Mac development space, where you see a lot of small teams who are able to create products that compete with those of much larger companies.
As a final note, using Cocoa gives you the ability to stay on top of the new APIs Apple is continually rolling out. We're now working on a new control interface that will make heavy use of Core Animation, something that would be painful to deal with using Qt.
I'm currently developing both with QT (actually PyQT, but it makes no difference to your question) and native Cocoa app. For me it's no brainer, I'd chose Cocoa. It's really worth time to explore Cocoa in general, there are many great concepts within the Cocoa framework, and Objective-C 2.0 as well.
I'd use Qt if you want this to be a crossplatform application.
You can have a look at the QMacCocoaViewContainer class. It acts as some kind of wrapper for generic Cocoa views, so you can also have Cocoa elements which are not officially supported by Qt.
Of course this means learning a little about Cocoa and Objective C and how a Cocoa UI would need to look like. But if you already know Qt well and if it’s not like your application is all and only about the GUI this could be a good way to go.
And don’t forget about the QMacStyle::WidgetSizePolicy or you won’t understand why your tables come out so huge.
Obviously, the best option is to use a cross platform suite that supports native widgets.
With QT4 you can build your base user interface. Then just add native support for your specific target platform.
Sure, Cocoa has a lot of fancy stuff (and you can still use them trough QT4), but let me be clear. I see a lot of fancy Apps on the AppStore, pretty ones, but most of then are just crap, expensive.. what ever. I really missed my Kate text editor, my okular viewer, my krita drawing software... those are just better than the commercial and expensive alternatives and are free. so i just tweak the source code a little bit too have a REAL native and great experience.
What if i have to use a linux app on my main computer with is a mac os x? or windows? or whatever? only?
For example, why on earth i have to buy a expensive ,fancy but far less featured image editor software for my mac like pixelmator when i can use a full featured real image manipulation software like Gimp? YES Gimp is gtk2 based which is a pain on any platform, specially on Mac because is really ugly. Gimp should be ported to QT4. Inkscape should be ported to QT4 too, and it would feel so great.
Is so simple to do.. gosh!
http://doc.qt.nokia.com/4.7-snapshot/demos-macmainwindow.html
Even you can add support for the the new native lion fullscreen feature, unified title and toolbar menus, etc
I , as a user, i really care about efficient, featured, good and cross platform apps, i don't really care about developer's convenience or laziness .
I do a lot of cross-platform development (Mac, Windows, Linux), and for some projects use Qt. It is a fine framework, and provides a rich class library. If you need to deploy on multiple platforms, cannot afford to spend the time/effort on platform-specific front-ends, or the "generic" support for each platform is sufficiently good, then use Qt.
However, Qt inevitably suffers in some ways from the lowest common denominator syndrome, and sometimes does not feel quite native enough. There are also certain features that are either difficult to support, or are simply not provided in the Qt libraries. So if you can afford the time and effort, or your app really demands the attention to detail and fit & finish, then developing separate front-ends may be worth it.
In either case, you ought to be writing your back-end (aka domain) code in a platform-neutral and front-end neutral manner. This way, the front-end is easily replaced, or modified between platforms.
You could always start with a Qt front-end and go for a quick time to market, then develop a native front-end down the line.
In practice, I've noticed that a Qt app on Windows looks most "native", while on Mac there are certain subtle telltale signs that make it look/feel not quite right. And Mac users tend to have much higher expectations when it comes to UI/UX!
Since posting this, i've been learning the Cocoa / Objective-C way, and have been quite impressed. Despite what I initially thought was quite a quirky syntax, Objc appears to be a very effective language for implementing UI code, and the XCode sugar - things like Core Data and bindings - make short work of all of the boring bits.
I spent a while with the QT examples and documentation before digging into cocoa, and tend to agree with what has been said above w.r.t being slightly behind the curve and less 'aqua-ish' - albeit from a fairly trivial inspection. If I absolutely had to be build a cross-platform app i'd probably use QT rather than trying to separate out the UI code, as it seems like it would provide close-enough visuals, but for mac only purposes, Cocoa seems like a definite win.
Thanks all for your responses, they've all been very helpful!
DO NOT use Qt for a Mac app. You will get no hardware acceleration for 2D rendering, and you will not be able to deliver ADA compliance.
Depending on what kind of apps you want to write, another contender is REALbasic now called Xojo.
The move from C++ is pretty easy (I have 15 years C++ experience) and the framework and IDE extremely productive. You have the added bonus of being able to deploy to Linux and Windows with trivial effort. Their framework compiles to native code and uses native widgets so you don't have an emulated look and feel.
The big reason for learning Cocoa and coding in Objective-C is if you want to hone your iPhone skills or are chasing a really fancy user experience. If you wanted to rival the cutting edge of WPF development then I'd recommend Cocoa.