RE: Starting XFree86 without an XF86Config file
Fortunately XF86VidModeSetGammaRamp() and friends allow these values to be altered by any application while the server continues to run. This means that a configuration program can write the data to a file, then have a simple user-mode app run as part of the start-up script which reads the data and passes it to the server via XF86VidModeSetGammaRamp(). No need for this data to reside in a root-owned X server config file. That is a help, but it doesn't totally solve the problem. At the beginning of the thread we were talking about the need for run-time and init-time configuration. I wasn't aware of this XF86VidModeSetGammaRamp() function but it seems it is the opposite of the other problems that were discussed. It _has_ run-time configuration but no init-time configuration. If an external tool is used, it will only solve the problem for some of the cases. Set-top-boxes need to display a splash screen asap, and nothing else until they are fully initialized. If the splash screen comes up before we are ready to accept clients then we can't have the correct gamma on the splash screen... It isn't so much of a problem that the gamma is slightly off, but that it will change while on-screen. Lets not get into the details of solving the gamma issue, given any single problem a solution could be worked out. The specifics aren't important. XFree currently has some init-time configurable parameters and some run-time configurable parameters. It would be a good plan to make any new configuration system/tool solve the init-time and run-time problems for all parameters. -Matt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Starting XFree86 without an XF86Config file
On Fri, 3 Oct 2003, Sottek, Matthew J wrote: Absolutely nothing says that both can't co-exist. If the default tools try to allow configuration of everything, even some hardware specific things, they can try where possible and feasible to generalize these things, or in cases where that isn't possible, they can provide hardware specific customization. Your example is exactly as I was suggesting, I just worded it badly. Try to put things in a generalized GUI but don't be too concerned about odd features that don't fit. Feature Foo that only applies to an odd usage case doesn't need to clutter the generalized GUI. As long as there is ability for someone to extend it in a device specific manner all will be well in the world. That would be fine. It depends on who writes the tool, what their objectives are, and what they're willing to accept into their project, be it hardware generic or hardware specific. Anyone can re-implement the whole thing in a different manner as you stated, but wouldn't it be nice if the de-facto one provided by XFree was the most flexible. In my opinion, no not really. That might be useful for Joe user who downloads XFree86 sources and compiles them himself, however if it comes with XFree86, then it will almost certainly use a 300 year old hideous widget set like Xaw or Xt, and thus look disgusting on today's modern desktops. A visually attractive tool which integrates visually into the user's desktop is IMHO much more perferred by the masses, which would mean using GTK+ or Qt for the majority of desktops out there, however that means it's very unlikely to be included in XFree86. Mostly a moot point however since distributions will ship software which works well, and integrates with the desktop they're shipping, so it doesn't much matter if XFree86 itself comes with the ubertool IMHO. I know I'd like a make install to have all the updated drivers and configuration tools without having to look for updated config tools from other sources. I disable/delete the config tools that come with XFree86, as they're too archaic. That sounds perfectly fine. And vendor in this sense could mean anything from open source project (including XFree86) to OS vendor to video hardware vendor. Yes exactly. Vendor is a misleading word. Whoever is producing the driver or config tools is the vendor. Fair enough. What would be nice IMHO for the future, is a unified tool which can use either GTK+ or Qt, and is distribution neutral. That would allow every distro to contribute to one tool, rather that the current mess of everyone shipping their own custom made GTK/Qt tool. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Starting XFree86 without an XF86Config file
On Thu, 2 Oct 2003, Sottek, Matthew J wrote: The thing is, a unified device-configuring front-end would be better than having every driver writer roll their own. (I mean, we can follow Windows if we want, but why incur development risk by developing what essentially is several versions of the same thing?) Windows does it the way it does for a reason (the Advanced button on the display prefs GUI) 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. Every vendor would like to have the ability to control unique features of their driver in a unique way. It is fine to standardize the basics, but if there is a Custom output filer Foo feature then the vendor should be able to design a custom GUI to control it. No matter how much you try to add to your standard GUI you will always have vendors that would like to control one more, or they will not like the controls for the features that exist. Absolutely nothing says that both can't co-exist. If the default tools try to allow configuration of everything, even some hardware specific things, they can try where possible and feasible to generalize these things, or in cases where that isn't possible, they can provide hardware specific customization. It depends on who writes the tool, what their objectives are, and what they're willing to accept into their project, be it hardware generic or hardware specific. Any hardware vendor, or other 3rd party is free to then roll their own tools in any way they see fit, and multiple tools can co-exist easily together, so both groups of people can have their cake and eat it too. What you are suggesting, attempts to limit one's choices, either as a user or as a developer. Thankfully, open source prevents such tunnel vision control. In such a world, the device driver would have to somehow describe what parameters it understands, what legal values may be assigned, and allow for a callback that would allow configuration setting and querying. Hmm. This isn't hard. XFree is basically just the man in the middle with regard to the config client program. The client says Foo filter = 4 and X passes that info to the driver without knowing or caring what that means. It can also save/restore the persistent data without knowing the details. I would advocate a config system that has a basic set of well known parameters. Width, Height, Depth ... maybe muti-display details too. And everything else is left up to the Vendor to implement in their own config program. That sounds perfectly fine. And vendor in this sense could mean anything from open source project (including XFree86) to OS vendor to video hardware vendor. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Starting XFree86 without an XF86Config file
Absolutely nothing says that both can't co-exist. If the default tools try to allow configuration of everything, even some hardware specific things, they can try where possible and feasible to generalize these things, or in cases where that isn't possible, they can provide hardware specific customization. Your example is exactly as I was suggesting, I just worded it badly. Try to put things in a generalized GUI but don't be too concerned about odd features that don't fit. Feature Foo that only applies to an odd usage case doesn't need to clutter the generalized GUI. As long as there is ability for someone to extend it in a device specific manner all will be well in the world. It depends on who writes the tool, what their objectives are, and what they're willing to accept into their project, be it hardware generic or hardware specific. Anyone can re-implement the whole thing in a different manner as you stated, but wouldn't it be nice if the de-facto one provided by XFree was the most flexible. I know I'd like a make install to have all the updated drivers and configuration tools without having to look for updated config tools from other sources. That sounds perfectly fine. And vendor in this sense could mean anything from open source project (including XFree86) to OS vendor to video hardware vendor. Yes exactly. Vendor is a misleading word. Whoever is producing the driver or config tools is the vendor. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Sottek, Matthew J wrote: 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: 1) Have a setuid root config tool that writes out the XF86Config file. Then have a method for X to re-read the config file and reconfigure itself at runtime. 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]
Re: Starting XFree86 without an XF86Config file
On Fri, 03 Oct 2003 15:55:47 -0500, Bryan W. Headley wrote: 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) This discussion needs an infusion of reality. I fully realize there are many graphics cards for which the color curves can be set exactly as you describe, as 3 arrays of 256 elements. The S3 Savages do it that way. However, the UI you describe is just silly. There is NO real-world reason to have a configuration widget that allows gamma setting on a point-by-point basis. For gamma, a single exponent (perhaps one exponent per primary) is the only thing that a UI needs to provide. Sure, there are specific applications that might need peculiar curves, or even non-curve mappings. Those applications can go talk to the API. The lesson here is that a configuration UI needs to expose the things that need adjusting; it does NOT have to expose every feature of the hardware. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Tim Roberts wrote: On Fri, 03 Oct 2003 15:55:47 -0500, Bryan W. Headley wrote: 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) This discussion needs an infusion of reality. I fully realize there are many graphics cards for which the color curves can be set exactly as you describe, as 3 arrays of 256 elements. The S3 Savages do it that way. However, the UI you describe is just silly. There is NO real-world reason to have a configuration widget that allows gamma setting on a point-by-point basis. For gamma, a single exponent (perhaps one exponent per primary) is the only thing that a UI needs to provide. Probably the most you want to do is introduce a slope to the curve of datapoints. Your single exponent, factored over some formulae. Fortunately for all, I don't write video drivers... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Tim Roberts wrote: On Fri, 03 Oct 2003 15:55:47 -0500, Bryan W. Headley wrote: 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) This discussion needs an infusion of reality. I fully realize there are many graphics cards for which the color curves can be set exactly as you describe, as 3 arrays of 256 elements. The S3 Savages do it that way. However, the UI you describe is just silly. There is NO real-world reason to have a configuration widget that allows gamma setting on a point-by-point basis. For gamma, a single exponent (perhaps one exponent per primary) is the only thing that a UI needs to provide. Erm, brightness would be nice, too. -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Starting XFree86 without an XF86Config file
Let me start by saying this is at least 5 years overdue. Glad to see David addressing this problem. I would like to suggest that a more aggressive approach be used that would involve (or allow) driver changes. Using external tools to figure out which graphics driver and input devices to use sounds like a fine idea; however, it seems that the driver should be responsible for determining a set of default settings. The driver is in a far better position to detect the monitor. Most drivers on other platforms have built in EDID parsing and methods to detect displays that may not even support such standards (Especially common in embedded market) Additionally the driver knows the availability of mult-display features from flat panel or TV encoders which cannot be determined without extensive hardware probing. This probing is already needed for the driver's operation and could be leveraged for a self-configuration purpose. A would suggest that a driver should initialize by the X server asking (rather than telling) the driver how many screens and what modes are supported. The driver can obtain this information from the XF86Config file when available or via it's own detection. The data is then written back to the XF86Config file at runtime. A runtime configuration (via randr, and additional protocols) would also allow for changing arbitrary display features at runtime and have them written back to the XF86Config file. Autoconfiguration is one overdue item, but runtime configuration is every bit a required 5 years ago feature that should be addressed in parallel since they have overlapping needs. -Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Dawes Sent: Wednesday, October 01, 2003 3:28 PM To: [EMAIL PROTECTED] Subject: Starting XFree86 without an XF86Config file The first part of the work I'm doing to improve the XFree86 configuration experience for users is now available. Some details about it, and a link to the source patch can be found at http://www.x-oz.com/autoconfig.html. The goal of this first stage is to make it possible to start the XFree86 server in a useful and usable form for most users without any prior user intervention. In particular, without first creating an XF86Config file. I'm planning to commit this before the next regular snapshot. The testing so far has been limited to the hardware platforms I have access to. Feedback is welcome. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Sottek, Matthew J wrote: The thing is, a unified device-configuring front-end would be better than having every driver writer roll their own. (I mean, we can follow Windows if we want, but why incur development risk by developing what essentially is several versions of the same thing?) Windows does it the way it does for a reason (the Advanced button on the display prefs GUI) 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. You're thinking of Window-dom: because the vendors HAVE to write something, they'd rather write something that distinguishes their product over another vendor. Improves the user experience. Puts up logos, and help screens, and shadowed widgets and whatever... If a vendor legimately thinks of a new/better way to describe a certain parameter, I'm more apt to accept a patch from them to implement new metadata/widgets than I'd want to see another binary on the system that can talk to/configure devices on my X system. Now, as to anyone who say, eww, it's Gtk, or it's Qt, or I hate Tk, I have only one thing to say to them: Athena Widgets. I would advocate a config system that has a basic set of well known parameters. Width, Height, Depth ... maybe muti-display details too. And everything else is left up to the Vendor to implement in their own config program. 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. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Starting XFree86 without an XF86Config file
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. Your cross platform GUI would provide 256*3 sliders and put 256*3 entries in the config file. It would work, but isn't useful. If you made 256*3 integers the standard then a lot of other hardware would have to convert that into a single integer. Multi-display: There are two multi-display concepts that XFree understands. 1) Dual Independent desktops. 2) Xinerama extended desktops. but it does not understand multiple screens for the same desktop... and it doesn't really need to. Some Intel hardware can do multi-display in four varieties. The two described above, and 3) Two screens with independent size and refresh using the same framebuffer, 4) Two screens with the same size and refresh using the same framebuffer. The configuration details for which displays can be turned on/off, panned/not panned are extremely complicated and probably require back-forth communication with the driver just to draw the GUI. You would of-course want unavailable displays to be drawn as such right? (Note: Even on Windows XP, Methods 3 and 4 are handled by vendors in their own GUI's. many vendors have this feature especially in laptops) Note my point: It is 100% possible to shuffle the configuration around in a device independent manner, in fact that it probably the best way to do it. Building a customer friendly way to interact with that data for all datasets is an entirely different problem. 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. 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. 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. In the end we can agree to disagree. As long as there is a protocol for configuring everything including modes, multi-display, and any possible parameter, there is no requirement that there be only one GUI tool. XFree could have a standard one and vendors (Linux distributions, HW Vendors, etc) could all make their own replacements as they see fit. -Matt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Sottek, Matthew J wrote: 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
Re: Starting XFree86 without an XF86Config file
On Thu, Oct 02, 2003 at 02:34:42PM -0500, Bryan W. Headley wrote: Now, as to anyone who say, eww, it's Gtk, or it's Qt, or I hate Tk, I have only one thing to say to them: Athena Widgets. Jesus, no. The point of this is that it's meant to be *easy* and *simple*. This means that it should integrate with the preferred environment. GNOME and KDE versions of the autoconfigurator will come, I guarantee you. The only reason that more people aren't really, incredibly excited about this is that very few people know. I assure you GNOME and KDE versions will come. Don't have none, have both. Red Hat can ship the GNOME version, SuSE/whatever can ship the KDE version, and they work the same way, semantically. Everyone's happy. -- Daniel Stone [EMAIL PROTECTED] http://www.debian.org - http://www.kde.org - http://www.freedesktop.org Configurability is always the best choice when it's pretty simple to implement -- Havoc Pennington, gnome-list pgp0.pgp Description: PGP signature
