I want to create a synthesizer for iOS5 and the interface that I have in mind is quite advanced to be made with the IB. So I was hoping there would be some tools or libraries for more advanced GUIs for iOS. Preferably I'd do this in C++ and use as little Objective-C as possible.
Here's an example of what it could become:
You could look at this as some sort of 2D game as I'll also need small animations etc.
Any suggestions of what could be helpful to me?
While the screenshot looks nice, it's not very complex IMHO. All I see are buttons, a segmented control and a custom LCD-like view. All of these can easily be done with Cocoa Touch, and you'd be even able to do most of this with IB if you want.
Since the native framework is Cocoa Touch and that one is done in Objective-C, it doesn't make much sense to use anything else unless there's a very good reason for a different framework. Since every other framework needs to use Cocoa Touch as well they are all by definition lagging behind Cocoa Touch, might not provide all the features and/or even introduce bugs on their own. If Apple adds new features, you'll have to wait until the third party framework makes use of it.
Additionally, you'll get the most support with Cocoa Touch: almost every (advanced) iOS developer can help you with Cocoa Touch issues, but if you use a third party framework there are a lot less people that can help you. That even starts with books: you shouldn't have a problem finding good books on UI programming with iOS using Objective-C/Cocoa Touch, but there are considerably fewer books on third party frameworks.
Animations are pretty easy in Cocoa Touch. For easier things the normal UIView animations are sufficient, but for anything more complex you'd add CoreAnimation animations. Apple has lots of guides and sample code on these topics on their developer site and usually they are pretty good.
Related
I'm just starting out with my Marmalade career with 6.1.
I'm aware they discontinued their UI builder in favor of 3rd party solutions. However, "Marmalade Ui Builder" in google brings up nothing in the first 3 pages (past 3 pages is always too far).
Are there such 3rd party tools? Or are people actually using notepad and writing ui's by hand?
I've seen an XML UI Builder that simply parses XML in to the .ui style. However, I don't see how that's any easier than typing everything out manually.
It also is ambiguous as to whether IwUI is actually the proper way to go about it anymore.
Some insight would be wonderful.
IwUI is old system replaced with IwNUI. N states for Native.
IwNUI uses native controls for each platform.
I have not used Iw*UI for games it is more simpler to write interface in GL myself.
Basic Screens/Buttons manager is coded in few hours.
It is simpler to write such thing your self then learn that is has something you can't change.
If you develop business apps then Marmalade added PhoneGap support. I believe PhoneGap to be a better way for business cross-platform apps. Especially because most mobile platforms share WebKit engine. What is more important Marmalade Team them selves do not believe in Iw*UI and that is why they are forcing PhoneGap on Marmalade.
In other words do not use Iw*UI if do not know why you actually need it.
There is 3rd party 2D game engine IwGame.
I do not use it but it has its own Interface Builder that defines interface in XML.
Is Qt an interesting platform for business apps development, outside of Nokia phones ?
Why ? Strong points ?
Thanks
I like Qt because:
Very well-designed framework, e.g. signal-slot, model-view, graphics view/scene/item/proxy, painter/paint device/paint engine..., too many to be listed here!
Excellent documentation!
Cross platform language/API, as well as tools like UI designer, creator, and so on.
Rich features, e.g. graphics framework, network library, database engine, and so on.
Active community, and active development.
There should be more. If you have ever used it, you'll find it's easy to build your framework upon Qt.
I didn't have any complain to Qt. If I have to say at least one disadvantage here, "convention". You must adopt the convention of Qt, e.g. You have to use moc to make the meta object of your objects, and it's easier for developers to use Qt's vector, list, auto_ptr than STL, tr1. But I never found any issue caused by that. On the contrary, it works very well.
In my opinion, Qt is the state-of-the-art C++ framework in this modern world!
P.S. There are a lot of commercial applications built on Qt. You can find it under Qt's official website. But I'd like add one more here: Perforce, one of the top commercial source code management tools, built its client tool on Qt for Windows/Linux/Mac.
yes it is .. just look at kde apps :)
or see more applications made by qt
and it has alot of bindings in many languages
Documentation
cross-Platform IDE
further reading
may be this is not so related to the question ... but my first deal with qt was just great starting from their well organized Documentation to their great widgets
the GraphicsView is just ammazing ! :)
It's about the only current/modern C++ gui library on Windows.
MFC is so old you have to write comments in Latin
WTL would be nice if they had finished it before abandoning it.
Winforms/WPF + managed C++/CLR - all the fun of several incompatible new technologies at once.
Bad points:
To fit on lots of platforms they have invented their own solutions to things that are now in the STL/Boost
The signal/slot mechanism - tricky to debug and silently fails (with no error) with simple typos.
Although everything is possible it's sometimes a lot of effort to do simple things (they do love MVC) compared to Winforms.
Qt is simple
Qt is powerful
Qt is NATIVELY-CROSS-PLATFORM
Qt is REALLY-CROSS-PLATFORM
Qt is comprehensive (but the Media side of it still needs to grow)
Qt doesn't require Garbage Collection, but it embeds a GREAT model of memory management that makes you forget about memory deallocation
Qt is solid
Qt is modern
Qt proposes some new paradigm of programming that are really good (Signals-Slots)
Qt runs a lot of VERY successful software: (Skype, Google Earth...)
Are those points strong enough?
Maybe you have heard about Google Earth which happens to be programmed in Qt too.
That aside, I like Qt for my in-house development because it
is very well supported and documented,
allows me to write simple and decent-looking apps that are
works cross-platform for Windows and Linux with little effort, and
contains nice to have components for database access, regexps, guis, xml, ...
I also use the Qwt widgets for easy real-time plotting on top of Qt.
I really dont understand whats the point in underestimating tools/frameworks which makes things easy for programmers. Qt is too good for GUI development, I would say its much better than any current existing crossplatform app development suite.
So many advantages, I have been using it for more than three years now for a product to be deployed in Linux/Win environments. The app is thread intensive and initially we had a tough time using pthreads and its conterpart for windows. Then we switched to Qt(and QThreads eventually) and things were a breeze...
Backed by active development, a highly helpful and supportive community along with excellent documentation, training, certification programs, videos, forums... its easy, fast and effective to develop in Qt. You should see the video which they create a web browser in just five mins!
Its really 'cross platform', and it doesnt have a software wrapper(like Java does) to enable this which makes it faster. Cmon, we all know java apps have buttons which takes a second to respond to even a simple 'click'.
I hope Qt will someday do a take on Java. :D
after all, 350000 developers cant be wrong when they chose Qt.
Pixar uses Qt (or at least, used, as of 2005) internally for certain parts of their tool suite (called "Marionette" in the marketing) collectively called Menv, ("men-vee" for Modelling ENVironment)---at least for their lighting sub-tool Lumos.
I have a significant codebase written in MFC and am tasked with creating a port for Mac OS X. I know that I'm going to have to roll up my sleeves at some point and do alot of grunt work to get everything working correctly, but are there any tools out there that might get me partway?
I'm working on one.
From the GUI point of view, the new version of AppMaker is based around an import/generate model. Most of commercial work I've done with AppMaker has been the other way, porting Macintosh applications to Windows. However, there's no reason why the same principles can't be applied in reverse.
AppMaker v2 had a very good importer for PowerPlant UI resources and traditional Mac dialogs. As it is only able to run on Classic, that code base has been discarded (you really don't want to know) and the final generator languge I wrote for AppMaker v2 is an XML exporter which dumps the entire object model to an extended XAML.
I already have a XAML UI generator and am currently working on a Cocoa xib generator - one of the reasons for going to WWDC in June. The focus at this time is on import/generator suites before returning my attention to a GUI editor.
I wrote PP2MFC to allow PowerPlant applications to be compiled for Windows - a cross-platform solution needed because no other framework or cross-platform tool at the time (1997) would perform well enough for the hardware requirements. I've since discussed an opposite program with someone I could chase up and I'm sure an MFC portability layer could be created to map to Cocoa objects. Whilst many developers have a poor opinion of MFC's message-map architecture, the heavily macro-based API sits on top of a reasonably clean OO framework.
This is the kind of project where you need to think about long-term maintainability - do you want something which ends up as large chunks of MFC code working with Cocoa or do you want to migrate to an idiomatic Cocoa program.
Any further discussion should probably be taken off SO - contact me at dent at oofile.com.au but I'm happy to debate technicalities and feasibility on here. The combination of code generation and skinny framework adaptor layers works better than most people expect.
Honestly, the models are so different that I suspect you're going to need to do a nearly complete re-code at least of most of the UI parts.
No, Such a tool would be pretty much impossible to write.
MFC and Cocoa are such fundamentally different platforms there is no easy way to convert between the two.
Depending on how you've written your applications, you will either need to write the GUI portion of your code or even the whole codebase.
I need a 2d political map of the world on which I will draw icons, text, and lines that move around. Users will interact with the map, placing and moving the icons, and they will zoom in and out of the map.
The Google Maps interface isn't very far from what I need, but this is NOT web related; it's a Windows MFC application and I want to talk to a C++ API for a map that lives in the application, not a web interface. Ideally I don't want a separate server, either, and any server MUST run locally (not on the Internet). What canned map package or graphics library should I use to do this? I have no graphics programming experience.
This is strictly 2D, so I don't think something like Google Earth or WorldWind would be appropriate. Good vector graphics support would be cool, and easy drawing of bitmaps is important.
All the canned options seem web oriented. SDL is about all I know of for flexible canvas programming, but it seems like making my own map would be a lot of work for what is probably a common problem. Is there anything higher level? Maybe there's a way to interact with an adobe Flash object? I'm fairly clueless.
Perhaps:
http://www.codeplex.com/SharpMap
ESRI MapObjects
http://www.esri.com/software/mapobjects/index.html
ESRI MapObjects LT
http://www.esri.com/software/mapobjectslt/index.html
See
http://www.esri.com/software/mapobjectslt/about/mo_vs_lt.html
for a comparison of the two MapObjects feature sets.
ESRI may have a replacement to the MapObjects libraries
You could extend your search by using the term GIS (Geographic Information System). I'm sure its gonna be easier. There's a lot of stuff out there on that subject.
Here's a page I found: http://www.ucancode.net/Gis-Source-Code.htm
or: http://opensourcegis.org/
You might want to try the Mapnik C++/Python GIS Toolkit.
You can take a look at the Marble Widget, which is part of KDE's Marble project. There are Windows binaries for this, too, but they might be dependent on Qt.
Yes, Marble has also the advantage that it provides kind of a ready made solution in a single control (called "widget" in Qt's technical terms).
The dependency on Qt (which is the only dependency btw.) might also be seen as an advantage: Qt's upcoming version is licensed under the LGPL, so even if you plan to use this in a proprietary application then there shouldn't be any real worries. And of course Qt and Marble are cross-plattform and provide an API that is very intuitive and easy to understand. Unlike common GIS solutions the Marble API and the usage of the widget is rather focused on people who don't know much about GIS. So its usage is quite easy to understand even if you feel scared by technical terms used in GIS.
Marble offers several interfaces to programming:
You can either create your own Marble plugins and paint inside those or you can subclass the MarbleWidget control. For a simple HelloWorld application see:
http://techbase.kde.org/Projects/Marble/MarbleCPlusPlus
We currently maintain a suit of MFC applications that are fairly well designed, however the user interface is beginning to look tired and a lot of the code is in need quite a bit of refactoring to tidy up some duplication and/or performance problems. We make use of quite a few custom controls that handle all their own drawing (all written using MFC).
Recently I've been doing more research into Qt and the benefits it provides (cross-platform and supports what you might call a more "professional" looking framework for UI development).
My question is - what would be the best approach to perhaps moving to the Qt framework? Does Qt play nice with MFC? Would it be better to start porting some of our custom controls to Qt and gradually integrate more and more into our existing MFC apps? (is this possible?).
Any advice or previous experience is appreciated.
In my company, we are currently using Qt and are very happy with it.
I personnally never had to move a MFC-app into using the Qt framework, but here is something which might be of some interest for you :
Qt/MFC Migration Framework
Qt/MFC Migration Framework
It's part of Qt-Solutions, so this means you'll have to buy a Qt license along with a Qt-Solutions license. (edit: not any more)
I hope this helps !
(This doesn't really answer your specific questions but...)
I haven't personally used Qt, but it's not free for commercial Windows development.
Have you looked at wxWindows which is free? Nice article here. Just as an aside, if you wanted a single code base for all platforms, then you may have to migrate away from MFC - I am pretty sure (someone will correct if wrong) that MFC only targets Windows.
One other option would be to look at the Feature Pack update to MFC in SP1 of VS2008 - it includes access to new controls, including the Office style ribbon controls.
It's a tricky problem, and I suspect that the answer depends on how much time you have. You will get a much better result if you port your custom controls to Qt - if you use the QStyle classes to do the actual drawing then you'll end up with theme-able code right out of the box.
In general, my advice would be to bite the bullet and go the whole way at once. Sure, it might take longer, but the alternative is to spend an age trying to debug code that doesn't quite play ball, and end up writing more code to deal with minor incompatibilities between the two systems (been there, done that).
So, to summarise, my advice is to start a branch and rip out all your old MFC code and replace it with Qt. You'll get platform independence (almost) for free, and while it will take a while, you'll end up with a much nicer product at the end of it.
One final word of warning: make sure you take the time to understand the "Qt way of doing things" - in some cases it can be quite different to the MFC approach - the last thing you want to do is to end up with MFC-style Qt code.
I have lead a team doing this kind of thing before (not MFC to QT but the principles should work).
First we documented the dialogs and what their inputs, controls and outputs were. Also, we create several test cases especially for any clever logic inside the GUI.
Sometimes we had to refactor some business logic to provide a clean interface the GUIs but this is the way it should have been done in the first place tbh.
Now we had a list of GUIs, inputs, outputs, tests and an interface that the encapsulated GUI had to match.
We began, project by project, to create equivilant GUIs to the old ones. Once we did that we could slot the GUI in where the old one was, rebuild and test it. At first we tripped a lot but we soon worked out the common errors and fixed them. We navigated (I think) 612 dialogs although there was a team of about a dozen of us working on it.