What are you doing now? I assume this is a real product; what are you putting into the XF86Config file now?
It was a hypothetical example. I don't know of a decent way to do it
with XF86Config short of 256*3 Options.
It's 3 curves of 256 datapoints. Floating point or integer. What you have to assume is that every point on the curve is grabbable, either through a spline curve widget, or something like
datapoint [123]^ red [ 45] green [ 23] blue [ 52]
With the premise being, you scroll to whichever element you want with the datapoint wheel widget; the values for red/green/blue are actually what you'd call red[123], green[123] blue[123] (only because in the example above, we're at the 123rd element)
Data storage isn't really
the issue. I could write a tool to write those options to the config file but unless every driver wants to receive its gamma data in that format it would be a device specific tool wouldn't it?
They who don't like it write a widget and a new metadata tag, and merge it back into the source. Then it supports what they want, and now you can leverage that widget if you want, and everyone can go back to making the value proposition the hardware.
Cross-platform? As in Windows and X? I never mentioned that.
Not cross OS. Cross hardware platform... as in device independent.
Aka, X. which we are, and it is...
Nobody does it now... that is the point. When building a GUI that will only generate working configurations for Multi-display you would have to know a lot about the hardware and probably communicate with the driver. That means the code behind the GUI is device specific.
Yes, you the hardware vendor have to know a lot. You have to send me meta-data that describes what widgets need to be put on a panel. Their type, whether they take integer or floats, and some field identifier. The program I'm think of will render the panel, query the driver for data, allow user configuration, and allow the data to be passed back to the driver.
Take a look at glade: it uses an XML format to describe the widgets and their layout. There's a library, libglade, that loads & renders the widgets. All you have to do is plug in the callbacks. The whole thing can be done in an interpretive manner. Look at that and imagine that being the meta-data the driver is asked to produce...
Wow, I've haven't seen such total FUD-mongering in a long time. Here, O vendor: if something doesn't meet your needs, you enhance it and give it back to the open source community. New widgets, new metadata... whatever it takes.
What are you talking about here?
You should read yourself. "This is all so hard that really the only one even capable of writing blah blah blah is ourselves..." C'mon. There's no brain surgery being done here.
My suggestion was simply that you are likely to find configuration options that, for whatever reason, do not fit cleanly into your driver independent GUI.
If you ever do think of something, once again, WRITE the given widget in question, IMPLEMENT the meta data, and SEND the patch in. And then the tool will support displaying/soliciting user input for whatever type of data you come up with.
In the meantime, you have a flat file that can represent strings, enums and integrals. As far as I know, it supports whatever your driver needs from it. Maybe not in the most sexiest way, but it's a start...
If every configuration parameter could be defined in a device independent manner, every driver in Xfree would use the same set of "Option" lines in XF86Config for the same purpose.
Metadata tells me what widgets to render; metadata tells the front-end what option parameters you understand/support.
There are two (at least) ways to get the config data stored:Then have a method for X to re-read the config file and reconfigure itself at runtime.
1) Have a setuid root config tool that writes out the XF86Config file.
That's the hard way. It's no different than running vi/emacs now...
2) Have wire protocol for altering configuration on the fly.Then have the X server write the data to the XF86Config file.
Number 2 is what I've been talking about all along. And that's writing at socket IO level to something that's running as root. THAT has to be audited to make sure there's no exploits. That's why I'd rather there only be one such program to audit.
It's interesting how when I was just discussing an idea, I now feel pushed into the corner of writing the damned thing just to show everyone that the simple is indeed possible. Fortunately, there's the crowd demanding separate Gnome/KDE versions, so I can opt out due to users' obvious insanity. Either that or make dynamic widget stuff like Glade work with Athena (which is even more insane)
<flame>
Seriously, if somebody replaced Athena with Gtk or Qt or Fox or ___, who'd be upset?
</flame>
-- ____ .:. ____ Bryan W. Headley - [EMAIL PROTECTED]
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
