What is Abstract intended to support?
Abstract eventually has to support all the features my applications use. That means supporting OpenGL, dialogs, standard dialogs, splitter views, toolbars, widgets (custom child viewpanes), reasonable 2D rendering protocol (points, lines, boxes, circles, text, etc.), preference management (registry), file and directory calls (filesystem) with endian translation, context menus, bitmaps, URL opening, and helper window management (e.g., proper docking behavior). No abstraction model is pure. There’s always some small underlying detail that requires an application to use some platform-specific code, such as fast bitmap processing. True enough. On OS X, for example, one cannot specify more than 253 primary command groups because they become visualized as menus, and the Mac uses 8-bit menu IDs. Windows, on the other hand, is more generous. As for bitmaps, that’s another good example — different platforms use different color channel ordering. Then again, that can be part of the abstract inte
Related Questions
- When the escrow company discovers the support lien or abstract of judgment recorded by DCSS, whom do they contact and what information do they need to request a "demand"?
- If I have to contact DDW Administration or the ScholarOne Support team for information related to my abstract, what information should I have on hand?
- Does Shiva support the programming of custom shaders in cg, hlsl, or other abstract language ?
