Hello, For some time now i'm looking for an XML browser, witch is simply able to show XML documents. XML capable browsers that exist today do not suit my (and others who extencively use XML) needs. Their XML implementation is based on top of their html implementation, witch makes it incapable of many standard XML features and also makes them bloated. During my search I began to cave into the dillo source, and found the dillo widget system. Witch seems to be a good rendering system for digital documents, not just html. XML parsers already exist (libxml for example), and parsing XML is a lot easier than parsing html, because it has a much more strict syntax. An XML browser, maybe more acuratly named an XML viewer, is just as abstract as XML itself. It has no way to know how a partucular XML document has to be show'ed. For this purpose XSLT exists, it is able to "translate" any XML document into another. Thus creating a XML viewer is limited to being able to render one particular type of XML document, and having XSLT documents available to translate the rest. Luckily something like glade exists. Glade is an GUI development kit, using XML to describe the GUI's, and GTX+ to show them. Dillo widgets are an extention to GTK+, meanig glade can show them. Leaving the "problem" to creating the XSLT stylesheets te translate documents to glade-XML. The dillo widget is currently inside the dillo source, and only linked directly to dillo. how posible is it to seperate this, and have dillo widget inside a .so for example? As such an XML browser is not really aimed at the same goals als the dillo project (as far as i've read, correct me if i'm wrong), i'd apriciate the dillo widget into a seperate library. this way dillo and this XML browser both can use the same dillo widget system, without forcing me to include dw vith the XML browser. (and sync them constantly) I'm still only planning, so i'd like any comments on this idea, as well as tips and other ideas. maybe you also have comments on the level of integration dillo and the XML browser can have. Greetings, Môshe van der Sterre http://www.moshe.nl/ http://www.coecu.nl/ PS: Needless to say, i'm a little short on time, so my participation in any discussion might be low. PSS: I'll problably license the browser code itself GPL (just as dw), and the XSLT stylesheelts LGPL. As they might be usefull elsewhere. Mvg, Môshe van der Sterre http://www.moshe.nl/ http://www.coecu.nl/ Mvg, Môshe van der Sterre http://www.moshe.nl/ http://www.coecu.nl/
Hi, first of all, some time ago I planned to extract Dw from dillo, making an own library of it. I've polished it a bit so far, it can be downloaded at <http://www.dillo.org/misc_files/dw-core-0.1.0.tar.gz>. It is nothing "official" yet, but you should be able to play around with it. Notice that this only contains the core of Dw, not the specific widgets. However, it should be possible to copy them, but they need some (trivial) changes, to remove some dependencies from the rest of dillo. Furthermore, I already wrote some widgets, which are neither part of dillo (some kind of tree, a simple text box, and a widget, which may be used to toggle the visibility of another widget), these may be a start if you need something similar. On Tue, Mar 08, dillo-dev@moshe.nl wrote:
For some time now i'm looking for an XML browser, witch is simply able to show XML documents. XML capable browsers that exist today do not suit my (and others who extencively use XML) needs. Their XML implementation is based on top of their html implementation, witch makes it incapable of many standard XML features and also makes them bloated. During my search I began to cave into the dillo source, and found the dillo widget system. Witch seems to be a good rendering system for digital documents, not just html.
XML parsers already exist (libxml for example), and parsing XML is a lot easier than parsing html, because it has a much more strict syntax. An XML browser, maybe more acuratly named an XML viewer, is just as abstract as XML itself. It has no way to know how a partucular XML document has to be show'ed. For this purpose XSLT exists, it is able to "translate" any XML document into another. Thus creating a XML viewer is limited to being able to render one particular type of XML document, and having XSLT documents available to translate the rest.
Luckily something like glade exists. Glade is an GUI development kit, using XML to describe the GUI's, and GTX+ to show them. Dillo widgets are an extention to GTK+, meanig glade can show them.
Leaving the "problem" to creating the XSLT stylesheets te translate documents to glade-XML.
I'm in no way familiar with glade-XML, but there is at least one problem with this approach: dillo widgets are *not* Gtk+ widgets, instead, from Gtk's point of view, there is only one large widget (GtkDwViewport), Gtk+ itself does not care about the complex dillo widget tree behind. OTOH, coding the rendering yourself should be pretty simple.
The dillo widget is currently inside the dillo source, and only linked directly to dillo. how posible is it to seperate this, and have dillo widget inside a .so for example?
See above.
As such an XML browser is not really aimed at the same goals als the dillo project (as far as i've read, correct me if i'm wrong), i'd apriciate the dillo widget into a seperate library. this way dillo and this XML browser both can use the same dillo widget system, without forcing me to include dw vith the XML browser. (and sync them constantly)
There are no plans to make dillo use a Dw library, since Dw is changing frequently, so it would be necessary to have a new version of Dw for each release of dillo. However, there is a script within the dw-core tarball, which makes syncing very simple, see README.
I'm still only planning, so i'd like any comments on this idea, as well as tips and other ideas. maybe you also have comments on the level of integration dillo and the XML browser can have.
Perhaps there may be a (graphical) plugin, which reuses Dw for the rendering (so that your viewer may be ported). I wrote something about this some time ago (it is part of the documentation about the "rendering abstraction"). Anyway, graphical plugins are not to be expected in the near future, there are currently other priorities. Sebastian
participants (2)
-
dillo-dev@moshe.nl
-
Sebastian Geerken