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.
SVG Based GUI
1–6 of 6 posts
Re: SVG Based GUI
#2Probably 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:
Re: SVG Based GUI
#3Probably 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
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?
Re: SVG Based GUI
#4Probably 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
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.
Re: SVG Based GUI
#5Earlier quoted context omitted.
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 star…
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?
Re: SVG Based GUI
#6Earlier quoted context omitted.
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 star…
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.