SVG Based GUI
hi, is it possible to create GUI framework that is totally based on SVG and not on OS's native graphics controls?
like Form/application design -> SVG renderer library -> UI.
NOT Form/app deisgn -> Native Controls -> SVG renderer -> UI. Probably not the best idea. SVG is loaded with CSS/DOM baggage that would lead to all sorts of pathologies further down the road. In a way, it has been done before, with a far saner approach: is svg rendering has to be binded with css/dom structure? i mean, if you wrtire a renderer for specific purpose you could use direct syntaxing other than css/dom model right? even theoritically? Starting off, SVG is an XML encoding, which is a rather hairy thing to deal with. Just to get a feel for LOCs: https://github.com/GNOME/libxml2 There's also the web's (horrible) tendency to make a diarrhea of special-purpose tags and attributes--many of which could be subsumed by basic turing-completeness. Compare this to postscript, which was a relatively simple stack machine to begin with. And of course, if we start special-purposing things, we're no longer compliant with the standard, and it would be chaos to call it SVG at that point. yes i think if we have to write very customised version of svg rendering then it would be like writing another graphics system, why bother with svg then? on second thaught if xml is used for encoding and declaration of a perticular drawing, then what is used to render actual svg? is this again going on OS's graphical system? There are many SVG rasterizers out there. This one is okay: https://en.wikipedia.org/wiki/Librsvg Could just be that I'm a cross-platform guy, but it seems like most programs bypass the OS rasterization stack (rendering fonts/curves/polygons/etc. with open source libraries rather than native OS facilities, and sending the OS a finished bitmap). This choice probably addressed a mix of cross-platform consistency issues, as well as the lowest-common-denominator problem.