121–130 of 184 posts
Earlier quoted context omitted.
Also, it would seem that Mac users tend to spend more money on software, than the general PC user. [citation probably needed, but whatevs]
That could only be true if you ignore software for business (even small and medium business, not just "enterprise").
Earlier quoted context omitted.
That's my point. Learning the language just to use some platform specific non portable technology like Cocoa? No thanks. Better to stick with what's reusable, like C++ and Qt.
Iron law of native desktop app development: Code to your platform's native GUI API -- no wrappers. Or your user base will notice and one-star that shit. You have less of an excuse on the Mac, which has literally the best GUI API in Cocoa that anyone has ever invented.
Not so iron, if you have many platforms to manage. Usually it doesn't worth it to manage tons of separate toolkits for each platform, if there is no common abstraction at all. It's just too costly.
My favourite "OpenGL is simply not a good option for 2D text-heavy graphics."
I'm going to take a wild stab at the primary reason he develops on the Mac is his own comfort and expertise with it - which is fine, of course. With the advancements made in web tech today, I don't think all the performance reasons he listed ring entirely true. See for example Google Refine https://code.google.com/p/google-refine/ which is a similar tool to his Wizard tool, with a web front-end.
Your comparison of Wizard with Refine is misguided. The two products do completely different things. Refine "refines" data into a usable form. Wizard is a stats and visualization tool for understanding an already-clean dataset. Last I checked, Refine actually runs a local web server, even if its client is in the browser, so it's not that different from a native app. Wizard also does incredible amounts of visualizatio…
That said, he points out performance, which is a pretty poor reason nowadays.
Earlier quoted context omitted.
This is exactly why I stopped developing for native. If you want to fix a bug or tweak/add one little feature its a huge ordeal. Plus the 30% tax on non-recurring revenue. I'm glad he's doing mac apps. Less competition in the web space.
That's assuming that the app store is the only way to distribute mac apps which, unlike iOS, it isn't.
Earlier quoted context omitted.
Iron law of native desktop app development: Code to your platform's native GUI API -- no wrappers. Or your user base will notice and one-star that shit. You have less of an excuse on the Mac, which has literally the best GUI API in Cocoa that anyone has ever invented.
Iron law of native desktop app development: Code to your platform's native GUI API -- no wrappers. Not so iron, if you have many platforms to manage. Usually it doesn't worth it to manage tons of separate toolkits for each platform, if there is no common abstraction at all. It's just too costly.
If your app looking like shit will cost you significant sales -- as is the case for most productivity and design apps -- then yes, you have to port the GUI bits to each and every toolkit you're using.
Earlier quoted context omitted.
Iron law of native desktop app development: Code to your platform's native GUI API -- no wrappers. Not so iron, if you have many platforms to manage. Usually it doesn't worth it to manage tons of separate toolkits for each platform, if there is no common abstraction at all. It's just too costly.
If you don't mind your app looking like shit on all platforms, this is a viable strategy. A lot of specialist applications are like this: for example, I used to develop Qt-based GUI tools for robotics. If your app looking like shit will cost you significant sales -- as is the case for most productivity and design apps -- then yes, you have to port the GUI bits to each and every toolkit you're using .
Firefox, LibreOffice, VirtualBox and etc. If you don't know how to make good GUI using generic toolkits it doesn't mean it's not possible.
Anyway, if you buy application for its "looks" - there is something seriously wrong already. It should look good, no doubt, but it should be functional first.
>as is the case for most productivity and design apps
Completely the opposite. They tend to provide completely custom, not native looking UIs, and therefore using cross platform toolkits for them only makes more sense.
Earlier quoted context omitted.
> What's wrong in this case with the very good performance across many platforms (even tablets) of the SVG-backed RaphaelJS? So I attempted to determine the accuracy of this claim. I ran a benchmark from Kevin Roast [1] who seems to author a lot of Canvas demos. For each of the 8 tests in his benchmark, I recorded the FPS reading that I saw that was the lowest (e.g., framerate dropped to X at some point during the 5-…
In the sentence you quoted I'm referring to SVG, not canvas, and the "in this case" refers to mapping apps, not games. I never made any claims with regards to games. In the test you quoted the goal is to stress it until it could only handle 30fps (it says so on the page), so you necessarily must see 30fps for the test to go on to the next one. That is why your median score on the Mac is 29fps, because it degrades smo…
Earlier quoted context omitted.
> What's wrong in this case with the very good performance across many platforms (even tablets) of the SVG-backed RaphaelJS? So I attempted to determine the accuracy of this claim. I ran a benchmark from Kevin Roast [1] who seems to author a lot of Canvas demos. For each of the 8 tests in his benchmark, I recorded the FPS reading that I saw that was the lowest (e.g., framerate dropped to X at some point during the 5-…
In the sentence you quoted I'm referring to SVG, not canvas, and the "in this case" refers to mapping apps, not games. I never made any claims with regards to games. In the test you quoted the goal is to stress it until it could only handle 30fps (it says so on the page), so you necessarily must see 30fps for the test to go on to the next one. That is why your median score on the Mac is 29fps, because it degrades smo…