Awesome! Kudos to the Omni guys for opening up the code, rather than let it fall into obscurity. It will hopefully serve as a nice example of how to architect a professional app.
224 karma · joined April 26, 2011
http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf
This describes in some detail how they used the PTX backend and linked the host and GPU to perform matrix operations and so forth. Awesome stuff!
A much earlier version did support this common file format, but for some strange reason it was removed in 2.x.
A pgm/ppm file is a wonderfully simple format - it is basically a simple textual header followed by a binary dump of the image data. So it is trivially easy to parse and load or save. It is for this reason that it is so useful, for example when working on image processing algorithms, it is so convenient to export test data, intermediate results and so forth.
I hope they will (re-)add support for pgm/ppm files soon. If you think this would be useful too, please vote on the support site.
They clearly see the PC market in decline, and mobile/embedded is the way of the future, with Android as the dominant platform. Compare this to only a few years ago, when the Wintel duopoly reigned supreme.
For years, people have been talking about Linux taking on Windows on the desktop, but it hasn't really materialised. However, Linux has done something far more significant - leapfrogged the humble PC and become the platform upon which both so many Internet services and mobile devices are built. Exciting times...
The latest versions of ES and GL are largely, but not completely compatible AFAIK, with the desktop having a superset of features.
I had a manual process whereby I would draw all my prototype UIs in pencil on large sheets of paper, then use an A3 scanner to import them into a slideshow. The cumbersome part was creating hot-clickable areas to jump between screens. But it worked a treat, and enabled very fast turnaround of ideas.
I think workflow (or UX if you like) does not get enough attention in the early design phases, where people seem to like producing pixel-perfect mockups in Photoshop. The problem with this is that it takes you a very long way down a particular path, when you don't even know for sure if that is the correct way to go.
Photoshop mockups are time-consuming and expensive to make compared to rough sketching on paper. This app looks like a great solution in this space.
Do they simply not have enough confidence in their own flagship smartphone, with an apparently world-beating camera, to show an actual unretouched shot? A great way to crap all over the launch.
WebM was originally a proprietary codec called VP8, developed by a single vendor (On2 Technologies) with a single implementation and no real specification. It was purchased by Google, and an ersatz specification was extracted from the implementation.
I admire Google for what they are trying to achieve. But given both Windows and Mac ship with H.264 decoding support, and it is fast becoming the de facto format for mobile, the decision seems to be a no brainer.
The benefits of this particular setup include:
* all articles are under version control
* just do a `push` to publish
* easily run a local Jekyll server to preview articles
* use a real programmer's text editor (not some web form)
* Markdown is the best for tech articles
* write, preview and commit while offline
* code syntax highlighting
* integration of snippets (gists)
* variable layouts for different page types
* pages are static so are served fast
* easy to add comments with Disqus et al
* easily port your content anywhere
* keep images and other binary content alongside text
Which reminds me - dear $DEITY, when is HN going to support Markdown?!
While much of this was possible before, Markdown is so much easier for writing a programming/tech blog.
iFixit are a fine mob indeed!
The way people repeat these iFixit teardown costs as net costs and imply that there is a huge margin is utterly misleading (as has happened with various iProducts in the past).
These tear downs are useful and nicely done though - a great resource.
A bit? They had some prototypes with just the industrial design, some with just the software, some with just the performance - but none with all the aspects of the finished product. And they say they were a few months away?
The hubris behind this kind of thinking is astonishing. It would take nothing short of a miracle to pull together all these elements in such a short timeframe. There are so many inter-related aspects that would prevent this. Performance, battery life, weight, heat dissipation, software drivers, power management - must all be designed and working in concert for a successful product.
And that says nothing about the product positioning. Are there seriously millions of architects out there who have been saying: "Boy, I wish I had a small, portable computer screen I could sketch my ideas out on." ? There's a reason they have huge drafting boards - they think big, and need big spaces to sketch out their big ideas.
I love the way they were thinking outside the square, and there were some seriously cool ideas in Courier. But it seems much more like a groovy concept than a nearly shipping product.
For example, the event for when "Run Completes" will trigger the behaviour "if no output, hide Debugger". This can be switched to always hide to solve the described problem.
I realise this doesn't solve the resizing issue, but it's a very handy indeed and makes working with panes a much better experience.
The current tab appears to be the Home tab, based on the highlight. But this has nothing to do with your "Home" directory - it is merely the "default" page for the most common operations. These operations are used to manage your files - the names of two other tabs in this hierarchy. What would the user expect to find there?
The layout of the Home tab is visually confusing. There is no grid or use of whitespace to guide the eye, and it presents a non-uniform 2-dimensional array of controls of different sizes. At least the old toolbars being 1-dimensional meant the user could easily remember approximately how far along the toolbar to look for the icon - now the user must scan a far more complex terrain to find what they're looking for.
There are two different sizes and layouts for action icons. So Copy and Paste are large icons with text below, while Cut is a small icon with text to the right. Why? Presumably it is less frequently used, but the inconsistency is visually jarring and non-obvious to the user.
While some buttons cause immediate actions, others have a small down-arrow next to them, suggesting they will probably pop up a menu instead. This introduces another variation to the two button types, giving a third type. But some have a default action when clicking on the button itself (a fourth type), and only reveal a menu when clicking on the arrow - yet there is no visual indication of which behaviour a button has. (This is apparent in IE and Office also.)
A user may wonder what is the difference between clicking on the dark blue File toolbar tab, versus clicking on the menu button in the very top of the titlebar, versus pressing Alt to reveal the hitherto hidden menubar?
While the Manage ribbon tab appears at the same hierarchy level as Home, Share and View, it has a brightly coloured tab _above_ it labelled "Library Tools". Vertical lines suggest it is superior to the Manage item; yet presumably it is also higher than Home, given its placement and urgent red/orange background? What is the difference between pressing Manage and selecting Library Tools?
A user not trained in the intricacies of the Office Ribbon UI will IMHO be utterly baffled by the complexity exposed in this UI and the inconsistencies therein.
While it is laudable that Microsoft is attempting to refresh the design of this venerable component of Windows, this work seems to be little more than a reshuffling of features and shortcuts, rather than a rethinking of file management.
There's all this nice, theoretical stuff about URI design, HTTP verbs and stuff. So I went to actually implement this the other day, only to find that you can't actually do it properly without hacks, because HTML and browsers only support the GET and POST methods for FORMs. WTF?
Can you actually implement a set of CRUD pages for an entity without resorting to hacks like hidden _method fields?
Surely REST is intended to be used for more than AJAXy APIs?
Apple took a long, hard look at FCP (which has only incrementally changed in the last several years) and took the opportunity to overhaul its UI, workflow and feature set.
Necessarily, things will be radically different and confronting to users who have been used to the same product in the same way for a decade.
To get a v1.0 product out the door, you inevitably have to make compromises, and FCPX has numerous limitations as a result. But I'm sure they are already working on the next revision which will address the most urgent of these.
Also I think that many people do not really understand the new features and workflow yet.
But the cut-down Express edition is no longer; it was probably too much engineering effort to create two editions and get such a complex product out the door.
They lowered the price to make the product appear to a broader market, and to cover the Express-Pro spectrum. I'd say it's an aggressive move that makes it more accessible. Surely people are not complaining that it's more affordable?
After FCPX launch: "I can't believe they changed everything!"