|
Mac Development Tools?
We have an opportunity to develop a cross-platform app in C++ and one of the requirements is we deliver a native Mac executable. I have not a clue what the latest and greatest compiler and related tools are for the Mac OS X operating system - I assumed Code Warrior was still the weapon of choice, but it appears their support stops with version 9 of the Mac OS.
Anyone know what the preferred toolset is? Comments on the general condition of developing for and on the Mac are also welcome.
Thanks.
Ernie Jobs - Steve's meat eating brother
Tuesday, February 17, 2004
XCode
Prakash S
Tuesday, February 17, 2004
codewarrior _does_ support osx...what made you think otherwise?
also there is xcode/project builder...very good ide.
and realbasic of course for x-plat development :)
FullNameRequired
Tuesday, February 17, 2004
if the app has to be in c++, Id look at codewarrior and wxWindows.
FullNameRequired
Tuesday, February 17, 2004
My mistake - Code Warrior does indeed support OS X targets, thanks for pointing that out.
Ernie Jobs - Steve's meat eating brother
Tuesday, February 17, 2004
Xcode and Interface Builder ship free with 10.3 Panther. Pretty nice IDE, except I'd kill for code folding in the editor.
Interface Builder is great for laying things out and setting up the plumbing.
--Josh
JWA
Tuesday, February 17, 2004
Try to get the latest Developer Tools CD for Mac OS X.
It comes with a lot of utilities, performance analysis tools, documentation, examples and a lot more besides the primary tools XCode or Project Builder and Interface Builder.
mrc
Tuesday, February 17, 2004
However, much of the UI goodness of XCode will not be useful to you if you have to use a cross-platform library like wxWindows or QT. Nevertheless, it is a good C++ compiler that is bundled free with the OS, so you should take a look at it.
Nate Silva
Tuesday, February 17, 2004
As I understand it, if doing cross platform, your choices are RealBasic, wxWindows w/CodeWarrior, or the apple tools. RealBasic and wxWindows allow one code base total to compile on both. You say C++ only, so that's wxWindows.
However, that said, most professional quality cross-platform products in C++ do not use wxWindows. They have their own private UI abstraction layer/framework and/or custom UI implementations for each platform.
Dennis Atkins
Tuesday, February 17, 2004
I forgot to say the point - in this third case, the apple tools can still be used for the Mac side of things for a cross platform project.
Dennis Atkins
Tuesday, February 17, 2004
"I forgot to say the point - in this third case, the apple tools can still be used for the Mac side of things for a cross platform project."
thats a good point assuming compiler compatibility.
another point to remember is that the apple tooks in osx cannot target macos9 or less, so if you want to aim for the full range of mac operating systems in c++ you are better off with codewarrior.
(Dennis Atkins point about separate UI etc still apply here).
OTOH cocoa/xcode is a lovely combination, cocoa is a _very_ good framework...you will find it significantly easier to learn than most of the other frameworks out there.
FullNameRequired
Tuesday, February 17, 2004
I'm using XCode to develop a native Mac OS X application with a portable C++ core. I couldn't be happier with Interface Builder and XCode. The thin native layer is coded in Objective-C and Cocoa. It calls the C++ code. No problem. Using the debugger, I can step through from one language to the other -- seamlessly.
Plus, it looks like a first class Mac application (because it is!). I haven't used any of the portability libraries mentioned, but I'd make sure they produce something that looks and feels like something a Mac user would expect a Mac application to look and feel like.
Jeremy
Wednesday, February 18, 2004
Agreed, and don't be afraid of the weird objective C language - you'd just be doing your UI code in that, and it is totally compatible with both C and C++. You'll link to the cocoa objective C stuff on the mac version and to your windows ui layer on your windows version. A bunch of people have done this successfully, or so I am told.
Dennis Atkins
Wednesday, February 18, 2004
Ah! A bunch of people such as Jeremy here (was responding to Full Name).
Dennis Atkins
Wednesday, February 18, 2004
Having actually written an entire cross-platform gui layer (like wxwindows but smaller) that runs on MacOS9/X and Win9x/2k/XP, I'll just say you're in for some fun :) Well, actually the reason our project got so involved was because everything had to be skinnable. At any rate, I would just go with CodeWarrior - XCode may be free, but it's still half the speed of CW compiling. Plus, as was previously mentioned if you need to target OS9, then CW is your only way to go. Also, hopefully you're using vs.net 2003 on the PC side, otherwise there's a good chance you'll run into compile errors on the Mac side as CW is not nearly as forgiving as VC6.
jedidjab79
Wednesday, February 18, 2004
Why not use the Mozilla XUL frame work? Write your core logic in C++ w/ XPCom and use a XUL / javascript gui? Mozilla Firefox uses the toolkit and looks / runs awesome on every platform under the sun.
Andrew Murray
Wednesday, February 18, 2004
I suggest trying both XCode and CodeWarrior and see which you like better. Both have strong compilers. For the GUI I recommend writing platform-specific implementations over "cross-platform" libraries, unless your application is really really simple.
Dan Maas
Wednesday, February 18, 2004
If you go the WxWindows/CodeWarrior route, you can get a version of CodeWarrior for Mac OS X that has cross-compilation support for building Win32 apps. That would let you have just one project file and toolset for doing both the Mac and Win versions of your app.
Ben Combee
Wednesday, February 18, 2004
Ben, that's certainly a nice benefit, but I wouldn't say a single project file is a compelling reasong to go the wxWindows/CodeWarrior route. The type of application being developed should dictate what to use.
However...
I can't think of a case where wxWindows would be a better option than using the native APIs directly, but I'm sure there's a valid reason to do it in certain cases. The problem with GUI apps is that there are subtle differences between OS' that simply aren't captured in cross platform GUI libraries.
As I said before, I haven't evaluated wxWindows, but I'd be very surprised if it matched Cocoa feature for feature -- even things that don't make sense on Windows or Linux. Remember this: users don't care that your app looks the same on *every* OS. They care that it looks right for the OS *they* use.
From experience with my own app, the native layer is so thin I can't imagine a portability library would have saved me time. And... I've kept all my options open to do Mac specific things to keep the users happy. Same goes for Windows and Linux when I decide to port.
Jeremy
Wednesday, February 18, 2004
"I can't think of a case where wxWindows would be a better option than using the native APIs directly"
?? wxWindows uses the native APIs directly.
Im not sure what you are getting at? wxWindows just wraps them in a somewhat more convenient form.
"The problem with GUI apps is that there are subtle differences between OS' that simply aren't captured in cross platform GUI libraries."
not really...its all code, anything you can do in objective c/cocoa I can do in c++/wxWindows...for some of them you will need t otarget machO format to ensure you can call through, but thats not a problem. (codewarrior supports PEF or machO formats perfectly happily)
"As I said before, I haven't evaluated wxWindows"
ahh.
"but I'd be very surprised if it matched Cocoa feature for feature -- even things that don't make sense on Windows or Linux."
?? it doesn't need to..it provides a x-plat GUI rendered using native api. If cocoa has a set of features you need you can simply call them directly (assuming you are compiling to a machO target) from your code, in exactly the same way you would using cocoa.
"Remember this: users don't care that your app looks the same on *every* OS. They care that it looks right for the OS *they* use."
absolutely right. thats what wxWindows is designed to give you.
"From experience with my own app, the native layer is so thin I can't imagine a portability library would have saved me time. "
maybe, maybe not...as you said it would depend on the app.
"I've kept all my options open to do Mac specific things to keep the users happy. Same goes for Windows and Linux when I decide to port."
you can still do mac specific things if you are using wxWindows...why wouldn't you be able to? its just a framework, you can either do everything via the wxWindows framework (which just calls directly through to the native api anyway), or, where the framework doesn't wrap the native api itself you can call them directly anyway.
you lose _nothing_ in terms of GUI, functionality and flexibility and you gain a great deal in terms of using a very convenient and well designed framework.
FullNameRequired
Wednesday, February 18, 2004
Sorry, I didn't mean to put down wxWindows -- you obviously like it a lot -- but I just don't get it. Use wxWindows and then call the native API to do things wxWindows doesn't do? What's the point? Where there was one framework now there are two.
And I do lose something -- I can't use Interface Builder with wxWindows. That program has saved me a bunch of time.
Why would I trade my GUI development tools and API that does everything (not most things -- everything) for a portability library that replaces only a small fraction of my code?
From my experience writting Mac applications (and where there is a Mac application there is always the portability question), the real key is building a solid C++ core (or C if you're really keen). I just don't see the benefits to using wxWindows or any other portability framework, except perhaps in exceptional cases.
Jeremy
Wednesday, February 18, 2004
" but I just don't get it. Use wxWindows and then call the native API to do things wxWindows doesn't do?"
well..I dont do that. I use wxWindows, Ive never needed to go outside that for the GUI, and by using it I get one GUI code base that can be compiled for all the platforms I need.
I was merely pointing out that you _could_ if you wanted :)
"And I do lose something -- I can't use Interface Builder with wxWindows. That program has saved me a bunch of time. "
<g> nothing beats a good GUI designer, and interface builder is _very_ good.
"Why would I trade my GUI development tools and API that does everything (not most things -- everything) for a portability library that replaces only a small fraction of my code?"
:) if it replaces only a small fraction of your code, I have no idea why you would bother.
I use it for the portability, if I was producing a mac-only application (actually, osx only application) I would use XCode and cocoa without hesitation.
Having a single code base for the GUI is a _huge_ saving for me. If its not for you then you wont need wxWindows.
"I just don't see the benefits to using wxWindows or any other portability framework, except perhaps in exceptional cases."
I suspect that the difference here is the size of the applications we are talking about.
<g> if the GUI of the app consists of one or two windows and a couple of buttons then porting it is always going to be trivial.
Either way I hear what you are saying....as you said; a sold c++ core is essential (even if you are using wxWindows); the only thing we are disagreeing on is whether the best choice for a xplat GUI is to use wxWindows or to use separate code bases for each platform GUI.
Ive seen it done both ways and both approaches work, personally Ive found it to be a real saving in work and maintenance to use the wxWindows GUI framework....it hugely increases portability, it can go to windows, macos9, macosx, unix, linux etc etc etc without any real problems and using the same codebase, whereas taking the separate code base approach you will end up with a lot of different code to maintain.
FullNameRequired
Thursday, February 19, 2004
Resonably speaking, it's not practicle to target *every* platform just because your GUI library supports it. You'll probably hit Windows and Mac OS X, or Windows and Linux. Maybe all three. So we're not talking about dozens of platforms (except in rare cases where you're developing a chat client or something). The 2% of the code that deals with handling button clicks or widget layout can be easily written for a new platform. The 98% portable core can move without much fuss.
The more difficult aspect is making sure the program looks right for users of that platform. Dude, I don't know what Mac applications you use, but I won't use anything that looks like this:
http://www.roebling.de/wxDesignerX.gif
- None of the fonts are right
- The controls aren't placed according to Mac style guidelines.
- The OK and Cancel buttons are in the wrong order (on the Mac the OK button is on the right).
http://www.wxwindows.org/images/screens/audacity-osx-screen.png
- Check out the poor rendering of the resize box in the bottom right.
http://mahogany.sourceforge.net/screenshots/MahoganyAqua.png
- That list don't look right, and those column headers scare me!
Those are all ugly Mac apps. Moving your code to a new platform isn't as easy as recompiling. For example, Mac users prefer sheets over modal dialogs. Sheets block only one window, while modal dialogs block the entire app. Does wxWindow support sheets? From my google search of their site -- no.
What about drawers? Mac users like those, too. Again -- no. One more search. How about AppleScript? Mac users like to script their applications to automate tasks. Sadly, wxWindows doesn't support that either.
So... to use any of these three things that Mac users want, wxWindows developers would have to use the native Mac API. Using two frameworks doesn't seem like such a stellar option to me -- and that's ignoring the ugly look of wxWindows Mac applications.
What wxWindows give you is a lowest common denominator GUI framework. You're trading user satisfaction for development effort. In some cases this could make sense. However, I'll say it again: users don't care that you support twenty platforms, they care how well you support the one platform they use.
Jeremy
Thursday, February 19, 2004
Hi Jeremy,
"Resonably speaking, it's not practicle to target *every* platform just because your GUI library supports it. "
?? of course not, I wasn't suggesting that at all..usually I target only win32 and mac
"The 2% of the code that deals with handling button clicks or widget layout can be easily written for a new platform. The 98% portable core can move without much fuss."
yesssss........that depends on (a) whether 2% is a realistic figure for the GUI code and (b) exactly how big 2% actually is in terms of actual code.
It also depends on how portable that 98% actually is, depending on what the application is actually doing it may either be entirely portable, or hardly at all.
(file stuff through fsspec? thats not portable, etc etc etc)
" but I won't use anything that looks like this:"
??? so the designer is bad at graphic design <g> so am I..I hire a smart person who is good at it, they tell me what fonts to use and where to put them and I do what Im told.
that has _nothing_ to do with wxWindows.
"Check out the poor rendering of the resize box in the bottom right"
shocking stuff.
"That list don't look right, and those column headers scare me!"
yep, ugly as sin.
whats your point? I can make apps look that ugly using any framework you care to name.
"Those are all ugly Mac apps"
yes.
"Moving your code to a new platform isn't as easy as recompiling."
no.
"Does wxWindow support sheets?"
"What about drawers?"
its a work in progress I believe, they are in the process of creating a cocoa version now.
Im not sure how far along it is but last I looked it was progressing nicely.
<g> weakness of google I guess...check out the email archives for the latest progress Im sure its there.
"How about AppleScript?"
that would be a strange thing for a x-plat GUI framework to support I think.
"What wxWindows give you is a lowest common denominator GUI framework."
no, its not. what wxWindows gives you is a x-plat GUI which renders natively in all platforms.
"You're trading user satisfaction for development effort."
not unless you choose to. I tend not to, but you may if you wish :)
" users don't care that you support twenty platforms, they care how well you support the one platform they use."
absolutely true.
wxWindows provides a very good xplat GUI solution. Its up to the programmer to make sure that the application looks and feels like a native application on each OS, wxWindows just makes that process pretty easy.
The problem I think is that you haven't actually used it, and so genuinely have no idea what you are talking about :)
just out of interest, how do you feel about REALbasic? thats another x-plat framework, any thoughts there?
FullNameRequired
Thursday, February 19, 2004
You're talking around the real issue. Rendering natively and looking like a native app are two different things. I notice the one point of mine you didn't choose to comment on is the one about the OK and Cancel buttons being in the wrong places -- they should be swapped on the Mac. Using wxWindows, that's extra work coding layout on the Mac.
Also, one of the screen shots shows a tree control. That's NOT what it should look like on the Mac. The Mac uses disclosure triangles and not those +/- boxes. Using wxWindows, again, that's extra work to use a proper tree control on the Mac.
The font it's using isn't a graphic design thing. wxWindows has to do that because a bigger font (like the standard Mac system font) wouldn't fit. It would require a new layout. Again, more work to make it look like a Mac application.
I don't need to evaluate wxWindows or RealBASIC or whatever. I've used enough abstractions layers to understand there are tradeoffs. If you don't understand abstraction layers then go back and read Joel's article on Leaky Abstractions.
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
He says, "All non-trivial abstractions, to some degree, are leaky. Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions."
When you choose to use an abstraction you are making a choice to trade development effort for reduced control. wxWindows may be the best abstraction layer ever written, but there are still tradeoffs. I used CodeWarrior's PowerPlant on Mac OS 9 -- that was an excellent abstraction layer. But it still leaked. I've also used Java Swing. That's a terrible abstraction layer and it leaked a lot.
So lets review:
- A very portable core of an application can be built. We have the technology. This isn't rocket science.
- If you do a good job on the core, the UI layer should be thin.
- Users want an an app that looks right on their platform.
- Most cross platform apps only target two or three platforms -- not twenty.
Using Cocoa:
- Access to all Mac APIs.
- Looks like a Mac application.
- Use great tools like Interface Builder.
- Porting to the Mac takes work that is proportional to the size of the UI layer.
Using wxWindows:
- wxWindows uses most of the Mac API, but not all. Sometimes leaks.
- Recompiling doesn't make it look like a Mac application (despite using native widgets).
- Sometimes Mac-specific code must be written (extra work).
- Can't use time saving tools like Interface Builder.
- Porting to a new platform takes work that is proportional to the size of the UI layer.
So I'll ask again... what's the point? You're missing out on some great tools. It's roughly the same amount of time to make it look like a Mac application. You'll probably end up using a native API anyway. And... you've got to deal with one more level of abstraction.
FullNameRequired, I'm sure you're a good programmer and could deal with any abstraction leak presented by wxWindows -- be it a font size issue or a tree control that doesn't look right. But add up the amount of time it takes to fix all those issues and tell me if you've gained anything.
I'll bet it's too close to call. So... what's the benefit of wxWindows?
Jeremy
Thursday, February 19, 2004
"You're talking around the real issue. Rendering natively and looking like a native app are two different things."
thats true. but I think you are missing the point. The first is handled by the framework, the second is always handled by the programmers.
Even in cocoa I can make an application that looks and feels nothing like a native application.
"I notice the one point of mine you didn't choose to comment on is the one about the OK and Cancel buttons being in the wrong places"
<g> thats because it was a point so intensely trivial that I didn't want to waste my time on it. ah well.
"Using wxWindows, that's extra work coding layout on the Mac."
nope, its the same work. In both platforms the programmer is repsonsible for placing the buttons and specifying their text and their behavior.
"Also, one of the screen shots shows a tree control. That's NOT what it should look like on the Mac. "
yeah I know, luckily there is a third party equivalent that looks correct on the mac :)
"wxWindows has to do that because a bigger font (like the standard Mac system font) wouldn't fit. "
:) sorry, but you are entirely wrong on this point.
"I've used enough abstractions layers to understand there are tradeoffs."
:) good, the next part of the learning process is to learn how important it is to understand exactly what they are before talking about them, they tend to vary depending on the subject.
wxWindows does require tradeoffs. In my experience they are not sufficiently large so as to be a problem, this will of course vary depending on your needs.
You dont have any experience in wxWindows so, really, you are not in a position to make that judgment call.
What you are doing in fact is pontificating on a subject of which you have no more than a _general_ knowledge, unfortunately what is required in this case is specific understand of the topic.
"When you choose to use an abstraction you are making a choice to trade development effort for reduced control"
no, thats not the tradeoff here. At _any_ point I can regain complete control over the appearance and behaviors by not using the framework and going directly to the native API in the same way that you would while using Cocoa.
There are tradeoffs, control is not one of them I am afraid.
<g> OTOH In my experience Interface Builder is an abstraction that does limit the level of control you have if you only ever design interfaces using it.
<snip comparison>
oh allright, Ill take it step by step.
the Cocoa set of points I have no problem with.
"- wxWindows uses most of the Mac API, but not all. Sometimes leaks."
:) but when it 'leaks' all you have to do is write the GUI code yourself in the same way that you would have had to do anyway if you were using Cocoa.
"- Recompiling doesn't make it look like a Mac application (despite using native widgets)."
indeed not, but it comes very closer indeed. Targeting other operating systems is always going to be a PITA, and this doesn't change with wxWindows, but it gets an awful lot easier.
"- Sometimes Mac-specific code must be written (extra work)."
thats _not_ extra work, the same code would have had to be written if Cocoa was being used..think about it, same GUI, same requirements.
- Can't use time saving tools like Interface Builder.
wow, you _really_ like interface builder dont you. It is pretty nice, but its an abstrction and as such it can become limiting quite quickly.
Its _not_ a solution, its a tool. Its not a magic bullet and its definitely not sufficiently impressive so as to be the 'killer feature' that forces a particular decision.
I suggest you try creating an interface without Interface Builder once in a while, its not that hard.
"- Porting to a new platform takes work that is proportional to the size of the UI layer."
??? This is true regardless of the approach used. Once the core has been created porting the UI to each new platform will be proportional to the size of the UI whatever method is used, isn't that right?
"So I'll ask again... what's the point?"
it saves me time, money and heartache :)
really, I think yo should go check out wxCocoa and see what state its in, you might be pleasantly surprised :)
FullNameRequired
Thursday, February 19, 2004
I might be pleasantly surprised, or I might waste my time. You haven't yet given me a compelling reason to do so.
Interface Builder isn't an abstraction -- it's a RAD tool. It produces the same results that I could get using Cocoa directly (just stored in a NIB file, but that's part of Cocoa). Where it doesn't do what I want, I write the code by hand. However, I'm not dropping down a level of abstraction -- it's all Cocoa!
You say that "Even in cocoa I can make an application that looks and feels nothing like a native application." What does that prove? In Cocoa it takes effort to make it NOT look like a Mac application. However, with wxWindows it seems to take effort TO make it look like a Mac application. This is a benefit how?
I don't think my lack of experience with wxWindows is an issue. I've had enough experience with UI abstraction layers in general to know there are limitations. Besides, if wxWindows were truly a must have for cross platform development, you should be able to give me solid reason before I dedicate time to learning it and dealing with the leaks that come with every abstraction.
If wxWindows could reduce the number of APIs I had to learn, that would be something. But it doesn't. You've said yourself that sometimes dropping into native land is the only way to get things done. Using wxWindows AND Cocoa doesn't sound like a plus
If it saved me time, that would be something. But it sounds like I have to redo layouts and use 3rd party tree-control solutions. So, the time to target a new platform isn't 0. As we've both agreed, it's more complicated than simply recompiling. I asked you to estimate how much time you spend fixing all these little wxWindows gotchas to make it look like a Mac application, but I didn't get an answer. My guess is it's a wash with just rolling a Cocoa UI and calling the core C++ code. So there isn't really and edge for wxWindows there either.
If it saved me money, that would be something. But Cocoa and wxWindows don't cost the developer anything (and take about the about the same amount of time to use), I don't see a big cost difference.
What's left... heartache? That I can't comment on! If you simply like the wxWindows API better, that I could understand. However, I've yet to hear a convincing arguement as to why another layer of abstraction is needed.
FullNameRequired, if you're going to argue the time or money angle -- give me some hard data. I want numbers, damn it! :) If there's another reason why the leaky abstractions of wxWindows should be tollerated, then I'd like to hear it. Otherwise, it seems to me a choice between wxWindows and Cocoa is purely preference.
Jeremy
Thursday, February 19, 2004
"You haven't yet given me a compelling reason to do so."
:) Im not likely to either, convincing you do move your code across is of absolutely no interest to me whatsoever.
"Interface Builder isn't an abstraction -- it's a RAD tool"
a RAD tool _is_ an abstraction. If you dont understand that then Id sit and think for a few more moments.
"Where it doesn't do what I want, I write the code by hand."
bingo, thats exactly the same thing that I do when wxWindows doesn't do what I want.
"What does that prove?"
it proves that whether an application fits the native look and feel depends on the programmer, not the framework used.
"However, with wxWindows it seems to take effort TO make it look like a Mac application."
umm..what? no, you get 80-90% of that for free. The applications you displayed earlier were designed by non-mac programmers and, frankly, showed it. Thats not the fault of wxWindows anymore than its the fault of cocoa that a windows programmer using it will invariably end up creating an application that is reminiscent of the windows feel.
"I don't think my lack of experience with wxWindows is an issue."
if course it is. Because of your lack of experience with wxWindows you are simply unaware of how big an issue it is.
"I've had enough experience with UI abstraction layers in general to know there are limitations."
yep :) there are limitations in everything, the question is how bad they are and where they lie.
"Besides, if wxWindows were truly a must have for cross platform development"
?? its not, I can think of a number of different frameworks and methods for doing xplat development, CPLAT, trolltech/qt, REALbasic, gnustep and the list goes on. Most of them are being used and are working perfectly well.
All I said originally is that its very good, and since then Ive also been busy refuting various points you have made about it because _they have been mostly incorrect_, because _you haven't used wxWindows_
seriously, use what you like but dont attempt to compare two frameworks in a setting like this unless you have used them both.
I agree with you, cocoa is very good. For x-plat development I believe that in general using wxWindows is better.
If you want to disagree with that, try using wxWindows before you do so....if you just want to point out that there are other perfectly valid ways of doing it (and that cocoa is very good) then make that point, but dont try and prove it by arguing that wxWindows is not as good because _you dont know_
FWIW I totally agree that there _are_ other perfectly valid approaches to use, I just happen to belive that wxWindows is, in general, the best solution.
I regularly work with people who disagree :)
"you should be able to give me solid reason before I dedicate time to learning it and dealing with the leaks that come with every abstraction."
heh. If you are interested...go check it out, if not...dont.
"If wxWindows could reduce the number of APIs I had to learn, that would be something. But it doesn't."
yes, it does.
"You've said yourself that sometimes dropping into native land is the only way to get things done."
yep, and youve said yourself that sometimes dropping into native land is the only way to get things done.
"Using wxWindows AND Cocoa doesn't sound like a plus"
:) why dont you try it instead of guessing?
" So, the time to target a new platform isn't 0."
LOL. you are looking for a 0 development time for each new platform? cocoa certainly wont get you that.
"I asked you to estimate how much time you spend fixing all these little wxWindows gotchas to make it look like a Mac application, but I didn't get an answer."
you _expected_ one? the answer is, of course, "it depends"
If you seriously expected to get a better answer than that then you have somewhat less experience in development software than I realised.
Have you used anything other than cocoa?
"My guess is it's a wash with just rolling a Cocoa UI and calling the core C++ code. So there isn't really and edge for wxWindows there either."
yep :) thats a guess.
You _could_ stop guessing and try out wxCocoa.
" I don't see a big cost difference."
between cocoa and wxWindows? nope. You aren't exactly comparing apples and oranges though, are you?
If you are targeting nultiple platforms then the true comparison has to be between:
writing C++ core, creating GUI in wxWindows for each platform
and
writing C++ core, creating GUI in Cocoa, creating GUI in a different framework for each targeted operating system.
In my experience the wxWindows approach saves time and money and long term maintenance.
"give me some hard data. I want numbers, damn it"
LOL, me too. Ill tell you what, you put together a spec for an application and provide hard figures for the time and cost involved in creating that GUI in Cocoa, MFC and..GTK
Once youve done that pass me the spec and Ill do the same for wxWindows for each of those platforms. Then, to test the figures, we will both write the thing and see how close our estimations come.
If you dont have time to do this, then I would appreciate it if you would cease asking me to :)
"Otherwise, it seems to me a choice between wxWindows and Cocoa is purely preference."
of course it is @ preference, there are a _lot_ of valid ways to do xplat development. But remember, the choice _isn't_ between cocoa and wxWindows, its between Cocoa and whatever other frameworks you will be using on each other platform vs wxWindows.
Just out of interest, what other GUI frameworks would you be using to target the other operating systems?
FullNameRequired
Thursday, February 19, 2004
The applications I displayed earlier were showcased on the wxWindows site. If the product can do better, then they should update their screenshots.
Look, I'm not trying to put down wxWindows. Obviously some poeple find value in it. I'm simply trying to find what it's value is to me. My original statement was based on my (significant) experience with GUI abstraction layers. The promise is never as good as the reality. Based on that experience, the value I'd assign to wxWindows would be low.
What I've learned from you about wxWindows is that it requires tweaking, 3rd party libraries, or native API calls to make it look like a Mac application. There's no surprise there. That's what I'd expect.
What I've been unable to guage is how much work that actually is. Is it less than rolling a Cocoa layer? How much less? Is it the same? Is it more work?
On the one hand you don't have benefit of Interface Builder (yes, I do like that product) to quickly layout and connect the UI, but on the other hand you are starting with an existing code base.
How much work would be involved in taking one of the windows in the screenshots and making it look like something developed with Cocoa + IB? If you could answer that for me (without telling me to go learn wxWindows) I'd be interested in a reply.
Jeremy
Friday, February 20, 2004
"If the product can do better, then they should update their screenshots."
<shrug> its not up to them, its up to the programmers who create the applications as to how they look.
"What I've been unable to guage is how much work that actually is. Is it less than rolling a Cocoa layer? How much less? Is it the same? Is it more work?"
Im not sure what you want me to say here...obviously I find/believe that its less work to use wxWindows across the board than it is to use a different framework for every platform; thats why I use it.
As I said in an earlier post, if I was aming only at the mac osxplatform Id use Cocoa without hesitation.
If I were going to aim at the two mac platforms Id prolly use MacZoop, Ive found it to be wonderfully elegant.
When I aim for win32 + mac I use wxWindows, its very well designed and extremely well supported.
"On the one hand you don't have benefit of Interface Builder (yes, I do like that product) to quickly layout and connect the UI, but on the other hand you are starting with an existing code base."
Im really not understanding your focus on Interface Builder, if you are aiming at multiple platforms then you only get to use Interface Builder on one of them anyway...its nice sure, but its only usable on one platform anyway, you _still_ have to deal with the other platforms.
" How much work would be involved in taking one of the windows in the screenshots and making it look like something developed with Cocoa + IB?"
once again, it depends entirely on what you want, for instance this one:
http://www.roebling.de/wxDesignerX.gif
isn't bad at all, Id shift the buttons and alter the font and be relatively happy with it.
So we're talking about 5 minutes work.
OTOH If I was going to redo it then Id prolly go a little further for my own satisfaction.
while this one:
http://www.wxwindows.org/images/screens/audacity-osx-screen.png
isn't great but its not bad either. once again if I was writing it for a client Id get someone good at design to improve it, and I suspect that they would and Id redo the thing entirely.
OTOH if all I was going to do was tweak it then none of the changes are big ones...Id alter the background color slightly (that grey always reminds me of a java app <shudder>) adjust the grow buttons, maybe tweak the colors and font along the bottom...nothing very big and it wouldn't take long at all.
"http://mahogany.sourceforge.net/screenshots/MahoganyAqua.png"
is the worst of the lot IMO and Id redo it.
For this one I would take a closer look at the wxCocoa project and see how its going, Id like to use the proper cocoa toolbar and resizers etc....
Ive really not looked closely at the wxCocoa project for a while so Ive no idea how far its got, but Id expect it to be pretty good by now, they were making great progress last time I checked up on it.
If its good enough to be used now then Id expect simply recompiling in wxCocoa to make a huge difference...be interesting to see whether they've nailed the cocoa toolbar etc yet.
<shrug> its all hairy fairy stuff, but the answer depends on exactly what the question is.
FullNameRequired
Friday, February 20, 2004
For posterity:
The third screenshot,
http://mahogany.sourceforge.net/screenshots/MahoganyAqua.png
is not a Mac screenshot. It's an example of (bad) Gtk+ theming on Linux. The titlebar is a dead giveaway: the buttons in the titlebar are wrong (there's an extra one on the right) and the font is wrong -- no matter how bad wxWidgets is on the Mac, it's simply not possible to mess up the titlebar like this.
You can also tell because it looks quite a bit worse than the actual Mac screenshots on their screenshots page.
Yes, you can say that wxWidgets doesn't look native on the Mac yet. But to pull out a Linux screenshot and claim it's a Mac screenshot to try to prove this point is simply despicable.
Liar Liar Pants on Fire!
Sunday, August 8, 2004
Outstanding discussion on the topic!
I will go Cocoa on Mac with C++ program logic and wxWindows on Windows. This helps me to avoid VC++.
Thank you very much. :-)
crispan
Tuesday, August 31, 2004
 Recent Topics
Fog Creek Home
|
![http://mahogany.sourceforge.net/screenshots/MahoganyAqua.png"](http://mahogany.sourceforge.net/screenshots/MahoganyAqua.png"){kind=link}