Hi
https://launchpad.net/x-kit - DontZap is an application written in Python which relies on X-Kit and allows users to set the "DontZap" option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
https://launchpad.net/x-kit - DontZap is an application written in Python which relies on X-Kit and allows users to set the "DontZap" option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
An app, a configuration framework with four differnet programs, all to twiddle one configuration line. Impressive.
(FWIW, pyxf86config already exists in Fedora.)
Bill
On Tuesday 31 March 2009 11:00:21 Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
https://launchpad.net/x-kit - DontZap is an application written in Python which relies on X-Kit and allows users to set the "DontZap" option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
An app, a configuration framework with four differnet programs, all to twiddle one configuration line. Impressive.
See, Ubuntu *does* contribute code back to the community!
Yeah, I'll sure to file that in my "this_is_worthless" mercurial branch.
This change will simply require a very small edit to a kickstart file, as I've attempted to explain to those in the C-A-Bsp thread.
-Adam
On 03/31/2009 11:55 AM, Adam Miller wrote:
Yeah, I'll sure to file that in my "this_is_worthless" mercurial branch.
This change will simply require a very small edit to a kickstart file, as I've attempted to explain to those in the C-A-Bsp thread.
FWIW, this will prolly get it done:
%post grep -q -s DontZap /etc/X11/xorg.conf append=$? if [ $append -ne 0 ]; then cat >> /etc/X11/xorg.conf << EOF Section "ServerFlags" Option "DontZap" "false" EndSection EOF fi %end
Can we all go home now?
On Tue, Mar 31, 2009 at 11:00:21AM -0400, Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
https://launchpad.net/x-kit - DontZap is an application written in Python which relies on X-Kit and allows users to set the "DontZap" option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
An app, a configuration framework with four differnet programs, all to twiddle one configuration line. Impressive.
And all of this for manipulating xorg.conf, which doesn't even exists on modern distros.
On Tue, 2009-03-31 at 21:43 +0200, Tomasz Torcz wrote:
An app, a configuration framework with four differnet programs, all to twiddle one configuration line. Impressive.
And all of this for manipulating xorg.conf, which doesn't even exists on modern distros.
Doesn't even exist *by default*. This is perfectly normal for configuration files in many applications, it's a relatively common system to have the file not exist by default and only need to be created manually or automatically if a default setting is required to be changed.
This doesn't make xorg.conf any less 'current' or 'valid'. It's still entirely supported by the X.org project and the only recommended / supported / possible way to change certain configurations. The only change from 'olden days' is that X is expected and configured to work without it being present by default, as long as you don't want to change any default settings.
I think people over-emphasize the scope of this change. It's only intended to be as I described above. xorg.conf is not at present nor is it intended to become entirely obsolete.
On Tue, Mar 31, 2009 at 9:43 PM, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Tue, Mar 31, 2009 at 11:00:21AM -0400, Bill Nottingham wrote:
An app, a configuration framework with four differnet programs, all to twiddle one configuration line. Impressive.
And all of this for manipulating xorg.conf, which doesn't even exists on modern distros.
You are obviously lucky enough to never had the need for a proprietary GPU driver, otherwise you'd be accustomed to seeing xorg.conf around...
Please note, pyhton-xkit is also a requirement for jockey (the tool to detect hardware with proprietary drivers available)
Tomasz Torcz wrote:
On Tue, Mar 31, 2009 at 11:00:21AM -0400, Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
https://launchpad.net/x-kit - DontZap is an application written in Python which relies on X-Kit and allows users to set the "DontZap" option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
An app, a configuration framework with four differnet programs, all to twiddle one configuration line. Impressive.
And all of this for manipulating xorg.conf, which doesn't even exists on modern distros.
yeah that's true, but all those emacs weenie's, and those dev's who supposedly want to protect everyone from shooting themself in the foot, want us who want to keep the X11 default regress to using an xorg.conf, when in reality it is them who should be doing the regression and using an xorg.conf to disable zapping!
On Tue, Mar 31, 2009 at 9:55 AM, Rahul Sundaram sundaram@fedoraproject.orgwrote:
Hi
https://launchpad.net/x-kit - DontZap is an application written in Python which relies on X-Kit and allows users to set the "DontZap" option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
Whoever want them, please be my guest:
http://orion.lcg.ufrj.br/RPMS/src/x-kit-0.4.2-1.fc10.src.rpm
http://orion.lcg.ufrj.br/RPMS/src/dontzap-0.1.2-1.fc10.src.rpm
I have some interest in x-kit, because it can be useful to alter xorg.conf.
dontzap is just a bonus ...
Paulo Cavalcanti wrote:
Whoever want them, please be my guest:
http://orion.lcg.ufrj.br/RPMS/src/x-kit-0.4.2-1.fc10.src.rpm
http://orion.lcg.ufrj.br/RPMS/src/dontzap-0.1.2-1.fc10.src.rpm
I have some interest in x-kit, because it can be useful to alter xorg.conf.
dontzap is just a bonus ...
dontzap
https://bugzilla.redhat.com/show_bug.cgi?id=494518
x-kit
https://bugzilla.redhat.com/show_bug.cgi?id=494517
Rahul
On Tue, Apr 7, 2009 at 11:51 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
dontzap
https://bugzilla.redhat.com/show_bug.cgi?id=494518
x-kit
I guess x-kit should be instead python-x-kit, or (IMHO even better) pyhton-xkit like ubuntu does
http://packages.ubuntu.com/intrepid/python/python-xkit
On Tuesday 31 March 2009 14:55:11 Rahul Sundaram wrote:
Hi
https://launchpad.net/x-kit - DontZap is an application written in Python which relies on X-Kit and allows users to set the "DontZap" option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
Rahul
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
Michal
Michal Hlavinka wrote:
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
If and when the RFE's gets accepted, maybe. I wouldn't count on it. Meanwhile, x-kit is being used by a number of other programs and useful to have in the repository. If you have x-kit, dontzap is just a small script. No big deal.
Rahul
On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
Michal Hlavinka wrote:
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
If and when the RFE's gets accepted, maybe. I wouldn't count on it. Meanwhile, x-kit is being used by a number of other programs and useful to have in the repository. If you have x-kit, dontzap is just a small script. No big deal.
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
The dontzap script is the wrong solution. Please stop suggesting it.
- ajax
Adam Jackson wrote:
On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
Michal Hlavinka wrote:
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
If and when the RFE's gets accepted, maybe. I wouldn't count on it. Meanwhile, x-kit is being used by a number of other programs and useful to have in the repository. If you have x-kit, dontzap is just a small script. No big deal.
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config.
I am aware of that.
Writing the change to the X log is stupid if
you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
Does that work currently?
The dontzap script is the wrong solution. Please stop suggesting it.
Do you have a current working solution that allows the users to easily revert the setting?
Rahul
Adam Jackson wrote:
On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
Michal Hlavinka wrote:
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
If and when the RFE's gets accepted, maybe. I wouldn't count on it. Meanwhile, x-kit is being used by a number of other programs and useful to have in the repository. If you have x-kit, dontzap is just a small script. No big deal.
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
The dontzap script is the wrong solution. Please stop suggesting it.
- ajax
well since the xorg devs decided to disable x zapping please suggest the right solution?
phil
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the right solution?
I said it. Right there. The bit about being a runtime XKB feature already.
- ajax (an xorg dev)
Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the right solution?
I said it. Right there. The bit about being a runtime XKB feature already.
- ajax (an xorg dev)
and you think an average user will know how to do this compared to installing rahuls dontzap package, and maybe just maybe when the next big change comes around in xorg you could let the community know beforehand instead of thinking your godlike
phil - glad not to be an xorg dev ;)
On Tue, 2009-04-07 at 21:02 +0100, psmith wrote:
Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the right solution?
I said it. Right there. The bit about being a runtime XKB feature already.
and you think an average user will know how to do this compared to installing rahuls dontzap package, and maybe just maybe when the next big change comes around in xorg you could let the community know beforehand instead of thinking your godlike
My godlike what?
All the other runtime XKB features are pretty well discoverable. gnome-keyboard-properties, layouts, layout options.
- ajax
Adam Jackson wrote:
On Tue, 2009-04-07 at 21:02 +0100, psmith wrote:
Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the right solution?
I said it. Right there. The bit about being a runtime XKB feature already.
and you think an average user will know how to do this compared to installing rahuls dontzap package, and maybe just maybe when the next big change comes around in xorg you could let the community know beforehand instead of thinking your godlike
My godlike what?
All the other runtime XKB features are pretty well discoverable. gnome-keyboard-properties, layouts, layout options.
- ajax
godlike as in taking votes on changes that will effect every xorg user in hidden polls, after all the discussions held previously and since were against the change, (apart for the few who hit keys aimlessly to see what happens or those who don't type to well) and not asking the community you are supposedly part of what they think, or even letting them know it was on the cards, anyway i've had enough of this i'll either patch the x source myself to put it back or live with regressing to using an xorg.conf, just to please the aforementioned few!
phil
On Tue, 2009-04-07 at 15:46 -0400, Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the right solution?
I said it. Right there. The bit about being a runtime XKB feature already.
Even though the time I most likely want ctl-alt-bs is BEFORE any login, and quite possibly before GDM has even run, because the video driver is b0rked?
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it as part of the user login process. Are we expecting people to be using Emacs at the GDM login screen?
On Wed, Apr 8, 2009 at 1:29 AM, Callum Lerwick wrote:
On Tue, 2009-04-07 at 15:46 -0400, Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the right solution?
I said it. Right there. The bit about being a runtime XKB feature already.
Even though the time I most likely want ctl-alt-bs is BEFORE any login, and quite possibly before GDM has even run, because the video driver is b0rked?
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it as part of the user login process. Are we expecting people to be using Emacs at the GDM login screen?
You sound desperate. I believe that it is best to save your energy for fighting with xorg people. While I find disabling c-a-b utterly stupid, I do not think this is the place that I should try to convince people.
Orcan, the "proud emacs user"
Callum Lerwick wrote:
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it as part of the user login process. Are we expecting people to be using Emacs at the GDM login screen?
Please stop rehashing the same old discussions in this thread as well. No need for the emacs conspiracy theory all over again.
http://www.fooishbar.org/blog/tech/x/ctrl-alt-backspace-2009-04-04-00-37.htm...
Rahul
On Wed, 2009-04-08 at 11:10 +0530, Rahul Sundaram wrote:
Callum Lerwick wrote:
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it as part of the user login process. Are we expecting people to be using Emacs at the GDM login screen?
Please stop rehashing the same old discussions in this thread as well. No need for the emacs conspiracy theory all over again.
Its not the same old discussion, its an entirely new suggestion. I mention emacs out of sarcasm, and perhaps a metaphor. Lighten up. It's still a serious suggestion. Notice how *I* have been trying to offer alternatives amenable to both sides, rather than just whining about reverting the change.
There have been THREE realistic suggestions for how to retain the functionality without nuking the functionality entirely, while still recognizing that ctl-alt-bs IS possible to accidentally hit.
1) Make the key combo more obscure. ctl-alt-lshift-rshift-bs
2) The SUSE patch, require hitting it twice
3) Enable by default, disable by default once in a user session.
All three are independent, and all three can be implemented if you think the X server hasn't been nerfed enough yet.
On Wednesday 08 April 2009 07:29:59 Callum Lerwick wrote:
On Tue, 2009-04-07 at 15:46 -0400, Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the right solution?
I said it. Right there. The bit about being a runtime XKB feature already.
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it as part of the user login process. Are we expecting people to be using Emacs at the GDM login screen?
<JOKE>And what about setting Conflicts: emacs in dontzap package ? :) </JOKE>
Anyway, I think this discussion is useless. Because there are not millions of grumbling users, there will be no will to change it...
* Michal Hlavinka mhlavink@redhat.com [20090408 10:51]:
On Wednesday 08 April 2009 07:29:59 Callum Lerwick wrote:
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it as part of the user login process. Are we expecting people to be using Emacs at the GDM login screen?
The emacs conspiracy is getting seriously tired now...
<JOKE>And what about setting Conflicts: emacs in dontzap package ? :) </JOKE>
*grin* Not a bad suggestion.
Anyway, I think this discussion is useless. Because there are not millions of grumbling users, there will be no will to change it...
There are some very vocal users that don't like the change. I had a look at the man page for xorg.conf and one argument that's been floated here is that applications grab focus and then misbehave.
Has anyone looked at and tested the AllowDeactivateGrabs and AllowClosedownGrabs options in their xorg.conf instead of blindly relying on C-A-Bs to shoot the server in the head? If they still have keyboard interrupt, these options may actually be a better solution than killing the entire X server.
Just a thought.
Alright, I can't resist it anymore, I just have to throw in my $0.02 (or €0.015). :)
This discussion has gone everywhere by now and it might be just me, but what exactly *is* the big deal here? Upstream decided to make a change to the shortcut behavior. It's been well spoken of by now. People have blogged about it. It's in the release notes (isn't that what it's for?). The excuse "people don't read release notes" does not apply at all here (IMHO). When they run into the "problem" they could have known it (what's the term again? RTFM?).
Besides the fact that it's disabled by default doesn't mean it can be reverted. There have been various solutions by now, they just need to be well documented to work. Sure, a checkbox in a configuration tool would be nice for the less experienced user, but is making a change to (perhaps a non existing) xorg.conf file that hard when it's been well documented? I guess it's just as hard as installing a 3th party piece of software which is currently not in the Fedora repo's. It'd require some knowledge of the software you're working with.
Please keep in mind that I'm just thinking out loud here. There are no bad intentions in my post and I'm not trying to defend the change (although I can live with it perfectly fine). I'm just trying to figure out what it's all about.
PS. Also, I might even have missed out on some important statements. Feel free to let me know if I'm (completely) wrong here.
Anders Rayner-Karlsson wrote:
Has anyone looked at and tested the AllowDeactivateGrabs and AllowClosedownGrabs options in their xorg.conf instead of blindly relying on C-A-Bs to shoot the server in the head? If they still have keyboard interrupt, these options may actually be a better solution than killing the entire X server.
I looked at them while struggling with https://bugzilla.redhat.com/show_bug.cgi?id=473825... they didn't work (probably because the actual problem in said bug was not, in fact, a bad grab, but something a little stranger). In the process of investigating them, I learned they had (reportedly) been removed in current X.org.
* Matthew Woehlke mw_triad@users.sourceforge.net [20090408 23:34]:
Anders Rayner-Karlsson wrote:
Has anyone looked at and tested the AllowDeactivateGrabs and AllowClosedownGrabs options in their xorg.conf instead of blindly relying on C-A-Bs to shoot the server in the head? If they still have keyboard interrupt, these options may actually be a better solution than killing the entire X server.
I looked at them while struggling with https://bugzilla.redhat.com/show_bug.cgi?id=473825... they didn't work (probably because the actual problem in said bug was not, in fact, a bad grab, but something a little stranger). In the process of investigating them, I learned they had (reportedly) been removed in current X.org.
So it has. http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f38b...
Thanks for pointing that out.
On Wednesday 08 April 2009 23:42:25 Anders Rayner-Karlsson wrote:
- Matthew Woehlke mw_triad@users.sourceforge.net [20090408 23:34]:
Anders Rayner-Karlsson wrote:
Has anyone looked at and tested the AllowDeactivateGrabs and AllowClosedownGrabs options in their xorg.conf instead of blindly relying on C-A-Bs to shoot the server in the head? If they still have keyboard interrupt, these options may actually be a better solution than killing the entire X server.
I looked at them while struggling with https://bugzilla.redhat.com/show_bug.cgi?id=473825... they didn't work (probably because the actual problem in said bug was not, in fact, a bad grab, but something a little stranger). In the process of investigating them, I learned they had (reportedly) been removed in current X.org.
So it has. http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f38 b47104a26c0524385
Thanks for pointing that out.
Is there actually any kind of replacement for this? Because I have had to use that feature many, many times (usually due to a browser "hanging", and yes, I know it would be nice to fix all the bugs, but ...).
On Wed, 2009-04-08 at 00:29 -0500, Callum Lerwick wrote:
On Tue, 2009-04-07 at 15:46 -0400, Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the right solution?
I said it. Right there. The bit about being a runtime XKB feature already.
Even though the time I most likely want ctl-alt-bs is BEFORE any login, and quite possibly before GDM has even run, because the video driver is b0rked?
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it as part of the user login process. Are we expecting people to be using Emacs at the GDM login screen?
This is an entirely reasonable idea, but again, gdm is completely capable of doing this itself without modifying xorg.conf.
- ajax
On 4/7/2009 3:37 PM, psmith wrote:
Adam Jackson wrote:
On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
Michal Hlavinka wrote:
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
If and when the RFE's gets accepted, maybe. I wouldn't count on it. Meanwhile, x-kit is being used by a number of other programs and useful to have in the repository. If you have x-kit, dontzap is just a small script. No big deal.
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
The dontzap script is the wrong solution. Please stop suggesting it.
- ajax
well since the xorg devs decided to disable x zapping please suggest the right solution?
How about trying this? 'Put it back in yourself'. ;-)
It looks like this.
Section "ServerFlags" Option "DontZap" "false" EndSection
David wrote:
On 4/7/2009 3:37 PM, psmith wrote:
Adam Jackson wrote:
On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
Michal Hlavinka wrote:
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
If and when the RFE's gets accepted, maybe. I wouldn't count on it. Meanwhile, x-kit is being used by a number of other programs and useful to have in the repository. If you have x-kit, dontzap is just a small script. No big deal.
Please. Stop talking about xkit. We have a library for this already, it's called pyxf86config. Writing the change to the X log is stupid if you can also do it as a runtime XKB change, like mapping Caps Lock to Compose like a sensible person.
The dontzap script is the wrong solution. Please stop suggesting it.
- ajax
well since the xorg devs decided to disable x zapping please suggest the right solution?
How about trying this? 'Put it back in yourself'. ;-)
It looks like this.
Section "ServerFlags" Option "DontZap" "false" EndSection
and since were supposed to be moving away from using an xorg.conf all of us who want to be able to restart x (and believe me as good as those xorg devs think their code is it still happens quite regularly) without having to go to a virtual terminal etc have to regress to using one to keep people who want to make linux like windows or those emacs users who don't type to well happy.
phil
On 04/07/2009 01:18 PM, psmith wrote:
David wrote:
Section "ServerFlags" Option "DontZap" "false" EndSection
and since were supposed to be moving away from using an xorg.conf all of us who want to be able to restart x (and believe me as good as those xorg devs think their code is it still happens quite regularly) without having to go to a virtual terminal etc have to regress to using one to keep people who want to make linux like windows or those emacs users who don't type to well happy.
So, an alternate suggestion is just don't upgrade to F11. I do not recommend that personally, but the new behavior is only in F11+ so if you don't upgrade, Ctrl+Alt+Backspace will continue to work.
Or, if you decide to upgrade, just use a kickstart file when you do. You've established you're going to be using anaconda to upgrade since in order to do a yum upgrade, you'd have to edit a few .repo files, and you've made it clear that you won't be editing files.
I already posted earlier in this thread[1] what the kickstart file has to look like. It's now also on fpaste[2]. Simply point anaconda to it by appending ks=[2] to the boot line, and then you will have an xorg.conf containing the needed lines to maintain Ctrl+Alt+Backspace.
No vts required.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-March/msg02161.html [2] http://fpaste.org/paste/8338/plain
devel@lists.stg.fedoraproject.org