Related
I've been recently investigating different multimedia frameworks for adding audio and video capabilities to my applications.
I've been looking at phonon, gstreamer, ffmpeg, libvlc/vlc.
However, I cannot find a good resource that answers some of my general questions.
Are these interchangeable?
Do they work in the same level?
Do you have any experience using some and can give feedback of why did you chose one over the other?
Thanks
Are these interchangeable?
generally not. Phonon is a high level api that wraps actual multimedia frameworks, which allows you to change the backend, but on the other hand limits what you can do.
Do they work in the same level?
no. some of the ones you mentioned are high level, some are low level.
Do you have any experience using some and can give feedback of why did you chose one over the other?
You should really tell what you want to do. Then people can advise what framework might be suitable. Lower level frameworks such as gstreamer cover quite a large variety of use cases.
There is a 'GStreamer SDK' for windows and OS/X which should get you started easily on those platforms (on Linux you can just install your distro's -dev packages). The SDK ships with snappy, which is a small media player using clutter, but you can easily build your own player using some other toolkit or API of course.
I am looking for tools and techniques for prototyping (virtual prototyping), simulation, and testing of deeply embedded C code on desktop Windows, including building realistic embedded front panels consisting of buttons, LEDs, and LCD displays (both segmented and graphic).
I'm specifically interested in a possibly low-level approach, using pure C code and raw Win32 API rather than MFC, .NET/C#, vxWidgets or Qt. I'd also like to use free development tools, such as Visual C++ Express with Platform SDK and ResEdit for editing resources.
I'm looking for code examples to render graphic LCDs (from monochrome to 24-bit color) with efficient pixel-level interface, multi-segment LCDs, and owner-drawn buttons that respond both to "depressed" and "released" events.
I am surprised that my original question triggered so many misunderstandings and adverse comments. The strategy of developing deeply embedded C code on one machine (e.g., a PC) and running it on another (the embedded microcontroller) is called "dual targeting" and is really quite common. For example, developing and testing deeply embedded code on the PC is the cornerstone of the recent book "Test-Driven Development for Embedded C" by James Grenning.
Avoiding Target Hardware Bottleneck with Dual Targeting
Please note that dual targeting does not mean that the embedded device has anything to do with the PC. Neither it means that the simulation must be cycle-exact with the embedded target CPU.
Dual targeting simply means that from day one, your embedded code (typically in C) is designed to run on at least two platforms: the final target hardware and your PC. All you really need for this is two C compilers: one for the PC and another for the embedded device.
However, the dual targeting strategy does require a specific way of designing the embedded software such that any target hardware dependencies are handled through a well-defined interface often called the Board Support Package (BSP). This interface has at least two implementations: one for the actual target and one for the PC, for example running Windows. With such interface in place, the bulk of the embedded code can remain completely unaware which BSP implementation it is linked to and so it can be developed quickly on the PC, but can also run on the target hardware without any changes.
While some embedded programmers can view dual targeting as a self-inflicted burden, the more experienced developers generally agree that paying attention to the boundaries between software and hardware is actually beneficial, because it results in more modular, more portable, and more maintainable software with much longer useful lifetime. The investment in dual targeting has also an immediate payback in the vastly accelerated compile-run-debug cycle, which is much faster and more productive on the powerful PC compared to much slower, recourse-constrained deeply embedded target with limited visibility into the running code.
Front Panel Win32 GUI Toolkit
When developing embedded code for devices with non-trivial user interfaces, one often runs into the problem of representing the embedded front panels as GUI elements on the PC. The problem is so common, that I'm really surprised that nobody here could recommend an existing library or an open source project, which would provide a simple C-only interface to the basic elements, such as LCDs, buttons, and LEDs. This is really not that complicated, yet it seems that every embedded developer has to re-invent this wheel over and over again.
So, to help embedded developers interested in prototyping embedded devices on Windows, I have created a "Front Panel Win32 GUI Toolkit" and have posted it online under the GPL open source license (see http://www.state-machine.com/win32). This toolkit relies only on the raw Win32 API in C and currently provides the following elements:
Dot-matrix display for an efficient, pixel-addressable displays such as graphical LCDs, OLEDs, etc. with up to 24-bit color
Segment display for segmented display such as segment LCDs, and segment LEDs with generic, custom bitmaps for the segments.
Owner-drawn buttons with custom “depressed” and “released” bitmaps and capable of generating separate events when depressed and when released.
The toolkit comes with an example and an App Note (see http://www.state-machine.com/win32/AN_Win32-GUI.pdf), showing how to handle input from the owner-drawn buttons, regular buttons, keyboard, and the mouse. You can also view an animated demo at http://www.state-machine.com/win32/front_panel.html.
Regarding the size and complexity of the "Front Panel Win32 GUI Toolkit", the implementation of the aforementioned GUI elements takes only about 250 lines of C. The example with all sources of input and a lot of comments amounts to some 300 lines of C. The toolkit has been tested with the free Visual C++ Express 2010 (with the Express Edition Platform SDK) and the free ResEdit resource editor.
Enjoy!
The appliances you mention in your comment clarification to the question will never be using a windows PC, so low level windows programming is not a requirement in that case. In fact, I'd say its undesirable. Prototyping is about speed. It's about how fast you can put something together to show potential investors or upper management or some other decision maker.
You wouldn't want to spend the extra time with low level C and Win32 api until the project requirements were flushed out enough that you knew that was an absolute requirement for the final project deliverables (perhaps a server/PC monitoring tool?). Until then you want speed of development. Lucky for you the industry has tools for rapid prototyping and development of hardware like you describe.
My Preference for Prototyping with Embedded Development
As for my opinion as a developer, I like the .net microframework (.netmf) simply because I'm already a Microsoft .Net developer and can transfer a lot of my existing skills. Therefor I prototype with a FEZ microcontroller using C# under Visual C# Express 2010 (free as you required). Its fast, easy and you are working on the core of your project in minutes.
If your experience as a developer is different, you may look for a micro controller which is programmed using BASIC, Java or some other language to help with the speed of development by reusing your core skill set.
Addressing your Question Bounty Comments
Astonishingly large portions of the embedded software can be developed
on the desktop computer as opposed on the deeply embedded target. This
avoidance of the "target system bottleneck" can potentially improve
productivity by an order of magnitude, if done right. However, to
develop embedded software on the desktop, one needs to simulate the UI
components, such as displays (both segmented and increasingly
graphical), LEDs, knobs, and buttons. I'm looking for such UI
components written in plain Win32 API in C for easy integration with
embedded code to be developed and tested on the desktop Windows.
I did embedded development full time professionally for well over 4 years as well as many years surrounding that part time. While what you said above is somewhat true, it will not save you time or money which is why everyone is confused about the motivation for this strategy. We spent years trying to put out a windows emulator for this company's hardware devices that would theoretically save time for prototyping. It was always a pain and we spent many more hours of work trying to emulate the experience than if we just went straight from sketched UI drawing specs to real development. The emulator lagged behind hardware development and often wouldn't support the latest features until 6 months or more after the hardware was released. It was a lot of extra work for very little value.
You will spend more of your time developing non-reusable win32 platform code and hardware emulation components than actually writing the code for the core project itself. This only ever makes sense for hardware vendors who provide this emulator as a 'value add' tool to potential 3rd party developers, but it does not make sense for prototyping new hardware designs.
Modern development environments like Visual C# Express 2010 with a FEZ microcontroller can compile, push the project output to the microcontroller, and then begin debugging just as fast or faster than you could compile and run a low level windows app in C emulating LCDs or LEDs or switches, etc... So your comment, "improve productivity by an order of magnitude", is simply no longer true with modern tools. (It may have been prior to the last 10 years or so.)
If you really, truly just want to simulate the embedded hardware visually on a PC use something like adobe flash to mock up a UI. But don't duplicate code by coding for windows when the final device you are prototyping won't be running windows (maybe it will be, but you didn't say that). Use the fastest most reliable prototyping tools available today, which is unequivocally not low level C and win32 api!
Maybe use StackExchange for Electronics?
Because this is a development oriented site, discussion about the merits of specific embedded hardware isn't really relevant. If you decide to refocus on using microcontroller electronics for prototyping (Arduino, FEZ, Propeller, Basic Stamp, Pololu, etc) you might ask for electronics hardware advice on stackexchange for electronics. I will say that most of those platforms are designed to facilitate the prototyping of LCDs, LEDs, buttons and interfaces as you outlined. You can usually assemble a few pre-built modules in a matter of minutes and be ready to start coding your project. Huge time savings can be had here.
You are asking for too much you need to take a look # proteus.
http://www.labcenter.com/products/vsm_overview.cfm
As Mahmoud said, you may find your code solution with prototyping example in proteus professional. It is one of popular software for prototyping, simulation and coding, you can download proteus professional for free and check their manual.
Best of luck
I was just wondering what software libraries are often used in professional commercial game software? I'm mainly interested in Windows, but Linux software interests me as well.
I've seen a lot of hobby projects / open source projects and the like using SDL, but I imagine very little commercial software uses it.
I know SDL does the following; I'm curious what alternatives are available (my educated guesses in brackets):
Time and Timers (Boost, Windows API)
Sound (DirectX (others??))
Graphics (OpenGL, DirectX)
Networking (DirectX, Berkley sockets)
Threads (Boost, Pthreads, Windows threads)
Event Based Joystick / Mouse / Keyboard Input (Direct X? Windows API?)
GUIs (C# winforms? Windows API)
Is a lot of this stuff proprietary depending on the company too?
I know there is no one-all-end-all, but I'm just curious about the industry and what are the de facto standards. Any info from experienced people appreciated.
Most Windows games use DirectX for pretty much everything (rendering, sound, input). OpenGL is used by multi platform games, since it works on Windows, Linux and OSX.
Some big games use engines that can use multiple rendering paths, such as Direct3D, OpenGL, and proprietary stuff for PS3, Wii, etc.
We are planning to develop an application for monitoring and configuring our service (which is running on remote server). After long time of discussion, we decided for python as platform for our app, because we love and know python. But we don't know, what GUI toolkit preferred for our aims. We need fast (for development and running) app, whose users will be Admins, Maintainers and Account managers.
There are two GUI toolkit for python, which we know: wxPython and pyQT.
Anybody have arguments regarding pro and cons? And maybe someone knows any commercial applications, using these products (only python version of toolkits)? Links are desirable.
Thanks.
I choose wxPython after much research. The reasons were:
"wxPython in Action" book by Rappin & Dunn
The voluminous examples that come as part of the wxPython download
The number of projects that have used wxWidgets
The fact that wxPython code runs equally well on Linux, Mac OS/X and Win32
I did consider pyQT and other researchers are successfully using it. After writing many examples in all API's that I considered, I found wxPython ticked the most boxes for me.
As for Tkinter (TIX), I think it looks rather dated.
Unless you are using IronPython or Jython I would not consider using the associated native windowing APIs. For another project which is to be delivered exclusively on .Net, I plan to use WinForms after lots of great feedback from StackOverflow members.
Well, I am a fan of QT: it has a more modern look and feel. However - your choice should be based on your actual requirements. Simple trade studies are helpful for this. Make a list of what features your toolkit must have and what features would be nice to have and then weight each item appropriately. Then look at all your options (TKinter also) and then score them according to your feature list (using the weights you assigned to each feature requirement). At the end it should be evident which one is right for your project.
I've always liked Qt's "signals and slots" conceptual model, though I guess it may take a bit of learning for developers who are more used to other models of event propagation and handling. Personally, given a choice, I'd pick PyQt because of this programming aspect.
You wrote "There is two GUI toolkit for python, which we know: wxPython and pyQT." You are forgetting about the most obvious toolkit: tkinter. That's actually part of a core python distribution, no extra downloads required.
Some people don't like Tk but that's often due to ignorance. Tk is a fine choice for a cross platform toolkit. It uses native widgets on windows (and has for many years) and the latest versions of tk use themed widgets on all platforms.
i've been using wxpython for 3 years .. and now we had to switch into pyqt since qt is integrated in maya 2011 .. however , wxpython is more straight forward and you can easily start working on it and learn it from zero fast .it provides and awesome resources and decumentation . but QT provides more powerful features that you cant find in wxpython , for example ( the multi touch detection) , QT also provides good support for drawing devices like pc tablets and so on .
qt also provides a good designer that makes u create interfaces faster.
one of qt disadvantages is it's license since it's not free like wxpython
A Windows (and Mono) option for a GUI toolkit is provided by IronPython. It provides access to the Winforms and WPF libraries. For examples, see Developing with IronPython & Windows Forms, and many others.
If you want to expand the list of options, consider building a Web App instead of a (local) GUI app. You say your service runs on a remote server, so networking is part of your requirements.
Once you start down that road, Python provides a bewildering amount of options.
I want to point out two strengths that wxPython has compared to pyQt:
It uses native widgets on every supported platform. So the apps have a native look and feel. I'm aware that PyQt uses native styles, but the behavior ("the feel") is reported to be somewhat non-native especially on the Mac.
It provides a wider choice of widgets out of the box.
You should also check out PyGTK. It is similar to pyQT in programming model but does not have any licensing cost since it is LGPL. I always found it nice to work with as a developer. The main drawback over pyQT is that in some cases they take away functionality in things like file chooser dialogs in favour of simplicity for the user.
Some of the requirements (restrictions) for such a ui framework/toolkit are:
No single vendor lock down
Ability for real time data visualization
Good initial widgets
Good dash boarding capabilities
cross platform
Good development/debug environment
No flash
It's a pity you can't/won't use Flash. Else I could really recommend Adobe AIR. It has a good editor (Flex Builder built on Eclipse), a good component framework with many out of the box components, charting components set, ability to communicate with many different protocols (and you could write your own protocol implementation), cross platform, runs in the AIR runtime and not in the browser, file IO, ...
I wouldn't pass over Flex/Air (Flash) without a closer consideration but here are a few others I have come across:
wxWidgets
GTK+
Qt
There is also a slashdot post with links to some tookits I haven't heard of. I'll add their recommendations here:
GLUI, an OpenGL-based GUI
Whisper, a Mac/Windows application framework
WxWindows, a framework which supports Windows 3.1/95/98/NT, and Unix with GTK/Motif/Lesstif, and MacOS
YAAF, Yet Another Application Framework, offering suport for Macintosh OS, Windows 95 and Windows NT, and X Windows
CPLAT, a framework for developing MacOS and Windows (Linux soon) applications
Ardi's Carbonless Copies technology, which is a portable rewrite of much of the MacOS API
For general information:
GUI Toolkit/Framework Page
PIGUI FAQ Page
C++ User's Journal PIGUI Page
I might suggest Mozilla XUL, but it has some drawbacks:
No really good development / debug environment (although there are tools and debuggers; they are variable)
You are locked into a vendor, but it is Mozilla.
It is very easy to use though and allows you to reuse your web Javascript skills for a rich-client app.
There's also Java of course. It satifies all your requirements AFAICS.
Plenty of custom charting controls, which are things you will struggle to find for GTK/WxWindows/$other_small_userbase_framework.
If you dont like Swing(its come a long way - Metal is dead, long live SystemDefault L&F!), there are options like SWT or even QT bindings for java(QTJambi).
For C or C++ go QT, its APIs are really nice.
For RCAs check out Eclipse RCP. For RIAs, you might be interested in OpenLaszlo. It's a rich internet platform that can compile both to Flash and DHTML.
http://www.gnustep.org/
"GNUstep is a cross-platform, object-oriented framework for desktop application development. Based on the OpenStep specification originally created by NeXT (now Apple), GNUstep enables developers to rapidly build sophisticated software by employing a large library of reusable software components."
Portable to: Windows, BSD-based systems, Linux-based systems, HP/UX, , Solaris, Sparc, GNUstep Solaris 10 U2 vmware appliance, OpenSolaris, others.
I recently made a pretty complete list here: http://commadot.com/ria-frameworks/
ExtJS is probably my favorite and we use that at work. I think it satisfies your list. Otherwise, there are a bunch of other possibilities on that page.