| 1 |
On Mon, Jan 18, 2010 at 4:30 PM, Dale <rdalek1967@×××××.com> wrote: |
| 2 |
|
| 3 |
> Alan McKinnon wrote: |
| 4 |
> |
| 5 |
>> On Tuesday 19 January 2010 00:29:18 Neil Bothwick wrote: |
| 6 |
>> |
| 7 |
>> |
| 8 |
>>> On Mon, 18 Jan 2010 19:53:16 +0200, Alan McKinnon wrote: |
| 9 |
>>> |
| 10 |
>>> |
| 11 |
>>>> Your post makes sense until you realise that the use of XML in a |
| 12 |
>>>> configuration designed to be changed by the user renders the package |
| 13 |
>>>> virtually unusable. Given a choice between me as a developer struggling |
| 14 |
>>>> with a config parser versus vast swathes of users dumping the package |
| 15 |
>>>> because of the same parser, I'd say it's me that has to work harder, |
| 16 |
>>>> not my users. |
| 17 |
>>>> |
| 18 |
>>>> |
| 19 |
>>> If we are truly trying to make Linux more accessible, with things like |
| 20 |
>>> the plug and play hal offers, should we even be contemplating editing |
| 21 |
>>> config files? |
| 22 |
>>> |
| 23 |
>>> XML is a machine-readable file format that just happens to use ASCII |
| 24 |
>>> characters, it is not meant to be modified by a text editor, so if your |
| 25 |
>>> program uses XML configuration files, it should include a means of |
| 26 |
>>> editing those files that does not include the use of vim. |
| 27 |
>>> |
| 28 |
>>> |
| 29 |
>> |
| 30 |
>> which almost by definition means you need an xml-information parser on par |
| 31 |
>> with an xml-parser to figure out what the hell the fields mean, then design |
| 32 |
>> an intelligent viewer-editor thingy that lets the user add-delete-change the |
| 33 |
>> information in the xml file. All the while displaying to the user at least |
| 34 |
>> some information about the fields in view. Shaes of .chm anyone? |
| 35 |
>> |
| 36 |
>> By the time you've done all that and made the thing semi-usable, you've |
| 37 |
>> expended more effort than if you had written you own xml-parser from |
| 38 |
>> scratch. In C, python and perl. Plus C++ for good measure just to show how |
| 39 |
>> clever you are. |
| 40 |
>> |
| 41 |
>> As said before by someone else, hal and everything about it is a classic |
| 42 |
>> case of "second system syndrome". It should be a comp-sci object case :-) |
| 43 |
>> |
| 44 |
>> |
| 45 |
>> |
| 46 |
> |
| 47 |
> I bet if hal had a easier to alter config file, I could have gotten my |
| 48 |
> keyboard and mouse to work. Having the config file in xml format would be |
| 49 |
> fine, IF it works out of the box with no configuring at all. Thing is, in |
| 50 |
> my case and a few others, it needed a little bit of help to work. Some |
| 51 |
> figured out how to make it work but my light bulb burned out and we all know |
| 52 |
> where that ended up. |
| 53 |
> |
| 54 |
> I suspect that the underlying part of hal works fine. It MAY have worked |
| 55 |
> fine for me if it was configured properly. The config part seems to have |
| 56 |
> been at least some of its shortcoming. Take hal, redo the config file and |
| 57 |
> try again. May work. ;-) |
| 58 |
> |
| 59 |
|
| 60 |
Or, at least provide a easy config UI (both X and non-X) for the XML files, |
| 61 |
so you never have to worry about the syntax or the complexity of the config |
| 62 |
files... |
| 63 |
|
| 64 |
-James |
| 65 |
|
| 66 |
|
| 67 |
> Dale |
| 68 |
> |
| 69 |
> :-) :-) |
| 70 |
> |
| 71 |
> |
Archives