[haiku-development] Re: Solarized Terminal color scheme

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

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

Not by much. Do you know, without thinking, that FFFFFFF is opaque white?
Can you tell what color
are 5453245, 4543262?

As you see, the text-based format does not make this more confortable to
edit, in the case of
colors. It is more readable/modifiable than a binary blob, but why would you
need to modify it
directly?

Because problems happens, and having things in text make the plan B option
viable.

Having things in a known and well defined format makes the plan B option
available. checkfs and bfs_recover are good plan B options for filesystem
corruptions, and they didn't require storing all filesystem data structures as
XML.


I think it's not. You can't see the colors in the XML, just numbers. So who
will really want to
edit the file manually?

I personally found that any binary blob format is hard to manage when you
need to fix it or make it
cooperate with other operating systems. Nowadays almost any serious DAW is
using XML for it's
project settings. Not because they are meant to be edited manually, but it's
still more manageable
than a binary blob in pretty much every situation. Outside Haiku any
flattened BMessage will be
harder to deal.

If you need inter-operability with other operating systems or apps, BMessage is
out of the way and so is a custom homegrown XML Kit. Better use the same code
on all platforms to read and write the files in that case (libxml is a valid
choice).


It's easier to use Terminal settings window or another color picker to build
your color palette,
than manually enter hex-digits in a text file.

Why not both? Using a text based format doesn't exclude this.

It will be slower to parse for the computer, and I don't see what we gain in
this particular case of Terminal color schemes. There are other cases where
having a text-editable file is useful, and for this we have the "driver
settings" format. It is both easier to edit manually, and faster to parse than
XML.


I think it is one of the worst examples you could have chosen, sorry :)

Well, so it seems there are hundreds of apps outside there that are flawed
:-), but i don't care
much right now if the majority think we don't need an xml_kit that's OK.

I'm not saying that. An "XML kit" or other way to handle XML can be useful
(apps like fRiSS where the XmlNode was developed would use it). But that does
not mean we should start using XML everywhere for setting files and whatnot. It
would augment our toolbox, not replace parts of it.

--
Adrien.

Other related posts: