You will never be able to create a GUI that covers everything that is configurable across a wide variety of vendor products... nor should you try.
Not true. Look at the limited vocabulary you presently have in XF86Config: keywords, list-of-values, integers, bools. Bools map to radio buttons, integers can have spin buttons, list of values are combos. Where's the problem? That the unified code doesn't know what parameters each driver support? That's the purpose of the metadata, so the driver can tell it.
Your example proves that you can use standard data types to convey the information. No argument there... but that wasn't the problem. The problem is providing a usable configuration tool. Yes you could map all the standard types to radio buttons, list boxes, etc without knowledge of their function and provide a good driver independent way to access the functionality, but in my opinion that isn't really a usable solution. Just as providing 100 options in the XF86Config file is possible, but not desired.
I'll use a couple real world options that would prove hard to map onto a driver independent GUI in any usable manner.
Gamma: Intel hardware can gamma control the output using independent 256 point mapping for each of red, green, and blue. You could have a very nice GUI with independent spline curves that could be point and click edited to generate the 256 points. The data would then just be 256*3 integers.
What are you doing now? I assume this is a real product; what are you putting into the XF86Config file now?
(Walking off, firing up glade-2. Hmm, it's got a widget called "Gamma curve". And another one called "Curve". That might not be enough; you really want a spline curve where the user specifies which of the 256 points they really want to set individually and the others which are interpolated.)
Your cross platform GUI would provide 256*3 sliders and put 256*3
entries in the config file.
Cross-platform? As in Windows and X? I never mentioned that.
Multi-display: There are two multi-display concepts that XFree
understands.
Different example, same response: what do you do now?
Anyone who is willing is welcome to tackle the problem. Try to build a complete GUI that satisfies all the configuration requirements. Maybe you will get closer than anyone did before, that would be great. However, in the eventuality that you discover something that just needs to be different for different hardware, I suggest you leave it alone and let a vendor specific GUI handle it rather than implement it in a way that doesn't meet anyone's needs. The more you can handle in the cross device GUI the better, but it doesn't eliminate the need and desire for vender specific additions.
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.
Same danger. You are writing to someone who's running as root (X). Big security concern. The less often you do it (e.g., one binary instead of every vendor rolling their own binaries) the more you can concentrate on making sure that binary is secure in terms of exploits.
It is a danger, but don't let existing XFree design characteristics prevent the user from having a good experience.
Agreed.
If you use the standard data types you were discussing above you can leave all the reading/writing to X. X gets 1000 data types that it knows nothing about and sends them to the driver. When the driver has verified them/applied them it can notify XFree to save them off to a file. It isn't hard to make that secure.
Web servers are supposed to be secure, too. And sendmail. But people keep finding all those darned root exploits... Anyway, we can all audit one program or try to audit (hmm, how many hardware vendors' products work with X?) num programs.
-- ____ .:. ____ Bryan W. Headley - [EMAIL PROTECTED]
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
