I am porting a windows only application to run on mac as well using Qt. We had a third party library for the spell checking on windows which isn't available for OS X. I would like to tie into NSSpellchecker using Objective-C or Objective-C++. I have looked around quite a bit and found one half solution of using a custom widget. We would prefer to have it abstracted out in a class that checks instead of the widget so as to not have to use a different widget depending on operating system. I am confident in my ability to write the class for checking and that shouldn't be an issue.
My question is if I will need to create a custom UI that houses the suggestions/options or if OS X has a stock spelling grammar panel that we can just tie into?
Does anyone have experience doing spell check with Qt on Mac? We are using Qt 4.8+ and targeting Win7 / Snow Leopard.
To answer your question I don't know and I don't think there's a stock Qt widget to do it. This list covers pretty much every Qt widget you can use: enter link description here
As a solution you can use hunspell (http://hunspell.sourceforge.net/) directly even on Windows. It's used in Libre and Open Office and also used by MacOSX.
And to implement it you can use QCompleter (enter link description here).
Related
I need to develop an application to interact with an FPGA through TCP in a Linux environment. Given that I'm mainly an OS X guy and have only had minimal exposure to Linux, I figure that writing in Qt, which I'm slightly familiar with, in OS X will be the easiest way to get the job done.
Anyways, I was pretty disappointed after getting set up with Qt Creator, given that I'm used to Xcode and Storyboards for iOS development. I'm sure that if I stuck with it I'd figure out my way around, but I don't plan on ever doing much Qt in the future; if I am making something that needs to look pretty, I'd rather do it natively.
Long story short, is there any way that I can use Xcode/Storyboards to create my application's UI? Or any alternative to Qt Creator that would better suit someone who's most comfortable with Obj-C/Cocoa?
Two options in Qt for designing UI
Programmatically, using the Qt class Widgets
Use Qt Creator's designer
I don't believe there is any current method to create the UI with Xcode and Storyboards. You could just use Qt Creator to design the UI, then import it into your XCode project, but learning Qt Creator and using it for what it does best is probably going to be easier for you in the long term.
Note that you can use Objective-C with Qt, in Qt Creator.
I have a friend who has an entry-level background in programming and is looking for a free GUI framework (IDE, GUI toolkit and GUI designer ) that:
He can use on Mac OS X to build Windows applications
It's very easy to use.
He is not interested in becoming a programmer, but would like to build an application for his work (not CS-related).
What are some good GUI frameworks/prog. languages he can use?
Qt including Qt Creater and Qt Designer is worth a try.
Especially, if your app should finally run cross-platform, on phones or on other embedded devices. Qt natively supports C++, but can also be used with 3rd-party extensions with Python (PyQt) and probably other languages.
On a Mac I have to recommend making Cocoa applications in Xcode written in Objective-C. Xcode is free to download and use, you pay if you want to submit applications to the Mac App Store.
I personally use Xcode every day and I think it's a great IDE. Currently has compiler support for Obj-C, C++, C and maybe more (not sure). More importantly for your needs, Xcode does a great job of integrating your code with its build in "interface builder" to help you quickly and easily create a nice UI.
NOTE: Xcode includes a new compiler feature (ARC) Automatic Reference Counting which is create for a new user. You can learn the language without having to worry about manual memory management.
Your friend should consider using PySide, a Python binding for the Qt GUI framework already mentioned.
With PySide you can use the Qt tools to create GUI elements interactively
and code your application logic in Python, which is a language often appreciated by non-programmers (and programmers too!) for its simplicity and intuitiveness.
Xcode includes a WYSIWYG editor for native controls and views. This was formerly a separate program called Interface Builder, but the editor was moved into the Xcode IDE at version 4.
AppKit is the framework it uses in most cases -- that's Objective-C. It's well supported. Your friend can also use it for source code editing and building and debugging apps. If he wants to write UIs programmatically, Xcode and AppKit are also good options.
I am thinking about something that would allow to develop applications independent of the GUI library, but allow Qt and GTK being plugged in as needed.
I'd just use Qt. It includes a Gtk-like style, mimics Gtk standard dialogs and even uses Gtk file dialogs if run under Gnome, so basically it integrates itself into Gtk as good as anything (except Gtk of course), or at least it integrates itself better into Gtk than Gtk does into Qt.
You can try to use wxWidgets but you tend to get "lowest common denominator" if you go that route. Your better bet is to design your software such that you can plug in an implementation of the necessary "views" in the desired toolkit, and keep your core UI toolkit independant.
Obviously this is more work, but if there is a strong business need, then so be it.
I don't know of any framework doing something like that (I don't know how it could possibly be done without suffering from a heavy "lowest-common-denominator" syndrome), but I do "cross toolkit" development (applications that use more than one GUI toolkit) and I wrote an article about why and how to do it:
http://www.hardcoded.net/articles/cross-toolkit-software.htm
You can try Tk, which supports themes. There is a tile-qt and tile-gtk theme. There is a 2010 Google Summer of Code project to improve these themes. And, of course, when you use Tk you also get support for Windows and OSX out of the box.
Qt is a framework, it uses GTK underneath (at least on Unix).
There was a mobile toolkit that let you write everything in JS but compiled to the native code on each platform. I forget the name but it was a victim of the iPhone lockdown.
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.
In the wikipedia article on Cocoa it says:
There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, Cappuccino, and Cocotron.
Yet when I looked into whether Mac application Tweetie was available for windows the developer had ruled it out:
Windows doesn't have Cocoa, the programming environment that Tweetie is made in, as such, it seems like a poor possibility.
I'd like to have an answer to point the Tweetie developers (and as a resource for other cocoa developers) which would tell them:
Which implementation is the most suitable for getting a cocoa app running on windows?
How much work is it likely to take to get the app running under windows?
How easy/hard is it to maintain a common code base for Mac and Windows?
(any other considerations I've missed?)
Of course if it would be too much work I'd like to know that too before suggesting it and potentially sending someone else on a fruitless search.
Don't forget:
“Major parts of the Cocoa frameworks” is not the same as “the entirety of the Cocoa frameworks”. Tweetie could be using something that's missing.
Tweetie could be (very probably is) using APIs from the non-Cocoa frameworks, such as Core Foundation, Core Services, Core Graphics, and Core Animation. A port of the Cocoa frameworks alone won't include any of these APIs, and even a more complete Mac-API-emulation framework will not include all of them.
These frameworks are eternally chasing Apple. Even if they catch up, they'll be instantly behind again as of the next Mac OS X release. Mac developers already put off using new APIs in new Mac OS X releases while they wait for users to upgrade to those new releases; now you're asking atebits to also wait for the other-framework developer to catch up to Apple again.
Any second implementation of an existing API will have bugs that the first implementation doesn't, and vice versa. These differences will cause development and support problems.
You're asking atebits to add a third platform to an application that already exists on two. Supporting one platform is a lot of work. Supporting two platforms is a hell of a lot of work. Supporting three? Now you're getting into big-company territory.
So, even with these Cocoa-like frameworks, the answer is: Hard.
Among GNUstep, Cappuccino and Cocotron, Cocotron is only possible choice to port a Mac application to windows.
Cappuccino is for web and GNUstep only runs on top of cygwin or mingw, which means the GUI looks nothing like native windows apps.
It is theoretically possible to build cocoa windows apps using Cocotron. However, the reality is that it is still very hard to use, and it is still quite limited in the Cocoa API.
Therefore, two possible solutions:
Try hard to remove the codes that are not supported by Cocotron in the original code base and do the cross compilation. Maintaining common code base will be painful.
Start a new GUI at all, no common code base. two choices here
Start a cross platform project with cross application framework such as Qt, or Java.
Start a windows only project. There are a lot of choices here, .Net WinForm application, MFC, etc.
There are Windows compilers for Objective-C (the programming language used to write cocoa apps). However, Cocoa includes the frameworks for presenting the GUI. These visual frameworks are specific to Mac OS X because they use OS X only windows and other controls. So someone would need to re-implement the controls in Cocoa to use Windows controls.
Also, I am fairly certain that Tweetie uses Mac OS X only technologies like Core Animation. This does not exist on Windows, so the nice animation effects present in the apps would have to be implemented in a completely different way.