Hacker News new | ask | show | jobs
SVG Based GUI
4 points by InnerGargoyle 1971 days ago
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.
1 comments
chaganated 1971 days ago
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:

https://en.wikipedia.org/wiki/Display_PostScript

link
InnerGargoyle 1971 days ago
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?

link
chaganated 1971 days ago
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.

link
InnerGargoyle 1970 days ago
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?

link
chaganated 1970 days ago
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.

link