I am looking for some web-browser control for Mac, which is the root of my project and any programming language which supports browser can be used for development,
I tried Mono but that does not support Browser control for Mac.
I am completely new to Mac-world, if there is anyone can show me a list of possibilities.
If you’re developing for Mac OS X, you should use Cocoa, the Objective-C framework developed, published, and supported by Apple.
For the Web browser component, you can use the WebKit.
Qt includes WebKit component. Usually Qt apps are developed with C++ in "Qt Creator" IDE. But Qt's WebKit implementation has several ugly bugs. Other WebKit implementations are better, but I don't know if they are available on Mac.
It is also possible to use Gecko XUL. But it looks more complex to me than Qt.
Related
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 would like to ask the SO community for the following information:
- Is it possible to compile WebKit for Windows8-Metro Environment, either in the form of a WinRT component or just as a linked library in a C++/XAML application?
- Which are the main steps to achieve this goal?
- Which are the possible things that would make this not possible or very difficult?
- Is it an endeavour someone is working on just now?
- Is it possible to gather interested people so they work on this?
I think you will not be able to just "compile" Webkit for WinRT/Metro Style. Metro Style applications are restricted in the kind of API calls they can make, for example there is no GDI/GDI+/MFC for WinRT. WebKit has several building modes that you can use, you can either build it using QT as rendering engine, or using GTK, or plain GDI, but on all those cases, when you create new builds for Windows OSes you will be using GDI at the very end.
Nevertheless, you could modify Webkit source code and add a new rendering engine that uses WinRT new APIs. You could probably become famous if you do.
As a side note, even when there is a "Windows Store" version of Chrome, by looking at the source code of Chromium it seems to me that this version is just a simple app launcher that communicates with the "normal" desktop version using an IPC channel. It does not appear to be a real Windows Store build of the whole source code.
I am not sure if the WinRT environment will allow this, but there is a project called Awesomium that is a wrapper around Google Chrome and Google Chrome is based on WebKit I think. It also has a .NET wrapper, so you can embedd it onto your .NET app.
I never tried using it, neither I know about if this library is applicable with WinRT, but at least it is a start.
Awesomium
Awesomium .NET samples
DownMakerWPF, an application embedding it to display markdown.
WinRT is a combination of managed and native code, so, you have a chance to port WebKit, but remember - native code have some sandbox restrictions.
Also you can choose XNA instead.
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.
I need to write quickly this application: a simple window that wraps
a web browser control, that runs html pages.
The Browser UI (e.g. Navigation buttons) should be suppressed.
As a .net developer, I would embed the WebBrowser OCX in a Windows Form.
But this has to run on Mac as well!
I found the following cross-platform candidates.
Which one would you choose (in terms of simplicity, stableness, community support, etc.):
wxWidgets: http://www.kirix.com/labs/wxwebconnect.html
QT: http://www.youtube.com/watch?v=Ee8eRwjbcFk&feature=related
MONO: http://www.mono-project.com/WebBrowser
Why not to use embedded Webkit?
QtWebkit:
The Qt port of WebKit currently compiles and runs on Linux (including Maemo), Windows, Mac OS X and Symbian.
Click here for build instructions.
A very simple test browser is built along with the port.
Since you have (assumption made from your post) .Net experience I'd go with Mono.
Have you considered Adobe AIR?
http://www.adobe.com/products/air/
Mono is probably the best choice if you're primarily a .NET developer and don't care very much about making a well-integrated Mac app (one that behaves like a Mac app in all the many ways Mac users expect). Given your problem space, that sounds like where you are. That said, pay special attention to this limitation from the WebBrowser page if it applies to your problem:
The Mono Webbrowser currently lacks
support for window.external, the
bridge that allows Javascript code
embedded in the browser to communicate
with the managed world using the
ObjectForScripting.
QT is very well established, and a great platform if you want to develop this in C++. Remember that there are licensing fees if this is a commercial app.
I've played a bit with wxWidgets. It's big advantage here is that it's probably going to be the smallest distribution, since you only have to include what you need. If all you need is the web browser, I'd look at this, but in my experience it's hard to make wxWidgets programs look good or act correctly on Mac (or on Windows for that matter).
Another option may be to write it as a Java app using the Eclipse Standard Widget Toolkit. This includes a browser control that embeds IE, Safari or Firefox, depending on the current platform, and generally behaves well on OS X.
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.