[haiku-development] Re: Solarized Terminal color scheme

  • From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 02 Sep 2015 10:14:38 +0000

2 septembre 2015 12:00 "Dario Casalinuovo" <b.vitruvio@xxxxxxxxx> a écrit:

Hi Adrien,

Here's one:

https://github.com/pulkomandy/fRiSS/blob/master/src/xmlnode.h
https://github.com/pulkomandy/fRiSS/blob/master/src/xmlnode.cpp

I've read your message the later week, but lately : p

Note that the usual way is simply saving things as archived BMessages (in
binary format), or, when
manual editing is needed, to use te driver_settings format and API (we have
a wrapper to parse it
to a BMessage). I'm not sure XML is a good choice in either case: when the
user doesn't need to
mess with the file, it is slower to parse than archived BMessage.

I suppose nowadays this doesn't make so much difference, also because of the
lookahead nature of
XML.

When the user needs to mess with the file, the XML syntax isn't the most
readable and easy to
handle one.

There are other factors though, XML is very well know out there and after all
not so much difficult
to be understood.

It give a lot of flexibility, it's used by the great majority of serious apps
which want a color
scheme (Intellij, eclipse, ardour...just to name a few). You can of course
create a more easier
syntax but is it worth? I mean that we can carefully think this, define an
Haiku's DTD and try to
provide reusable code instead of a very specific syntax.

XML itself is just a way to present information. I don't know if we can make an
1:1 bidirectional mapping with BMessages directly.

In the case of color schemes, you want the BMessage to use rgb_colors, but you
probably want the generated XML to be in a format similar to (and compatible
with) what other software uses. If your xml is a direct mapping of the BMessage
it would probably look like this:

<message>
<item type="rgb_color" name="foreground" value="0xFFFFFFF"/>
</message>

Which is probably not what you need.

On the other hand, if you start with an existing syntax, and manipulate it
using for example the XmlNode class I linked, you have to navigate it the XML
way (so you manipulate attributes and nodes). It is unlikely that you can do a
message.FindColor() on it.

There are more problems such as properly encoding raw data added to a message
with AddData() (probably it will need base64 or something similar), preserving
the distinction between children nodes and attributes from XML to BMessage, etc.

In the end you probably are better off parsing your XML in a traditional way
(SAX or DOM) and populating your BMessage from it using ad-hoc code depending
on the actualy contents (not syntax) of the data you are trying to parse.

--
Adrien.

Other related posts: