As promised in my previous posts, in this blog post I will deal with a project I’m working on which implements this blueprint.
Bryce Harrington (the mentor of this blueprint), Colin Watson (the approver) and I talked about this at the UDS in Prague. The blueprint is based on Bryce’s original idea to improve the Screen Resolution panel. The work was divided into 2 phases:
Phase 1 (which is a higher priority) is about providing the Screen Resolution panel with the capability to set the virtual resolution in the xorg.conf when, put simply, 2 or more screens don’t fit the framebuffer. Currently the Screen Resolution panel doesn’t succeed in such case since the drivers are not able to reallocate the framebuffer yet. A simple GUI should allow users to set the required virtual resolution and write the settings to the xorg.conf through PolicyKit.
Phase 2 is about adding an “Advanced settings” button to the Screen Resolution panel so as to allow advanced users to edit the xorg.conf through a simple GUI. The aim of such program is not to set up multiple screens layouts but only to make it easier for users to add, edit and remove options without having to know which section an option, say, DontZap, belongs to, or to switch to a different driver. A more detailed explanation of the use cases is available here.
In Prague we agreed that this project couldn’t become reality without an xorg.conf parser/writer and some other tools. For this reason I started the X-Kit project:
Components:
* XorgParser: a simple, transparent and easy to extend xorg parser.
* XorgValidator: a program which uses X-parser, tries to make sense of xorg.conf and operates accordingly.
* Xorg Options Data Store: a program which translates the content of the manual of the xorg.conf into an XML file.
* Xorg Options Editor GTK: a simple GTK GUI to the xorg.conf.
* Xorg Options Editor KDE: a simple GTK GUI to the xorg.conf.
NOTE: all the code is in Python
Aim:
* a desktop agnostic kit to manipulate the xorg.conf (and whatever will replace the xorg.conf in the future).
Advantages of XorgParser:
* Simple API.
* Easy to extend.
Current Status:
* XorgParser: version 0.3 is available. You can get the code from my bazaar branch or from my PPA
* XorgValidator: there is already some code in place which I haven’t released yet.
* Xorg Options Data Store: the program is complete, works well and will be released soon.
* Xorg Options Editor GTK (aka Phase 2): the program is almost complete and will be released soon. You can have a look at this screencast to see how it works.
* Xorg Options Editor KDE: not started yet
* Phase1: the Python part is complete and, as you can see in this screencast, it works well. The screencast, however, doesn’t reflect the current status of phase 1 but still gives an idea of how this will work in practice.
For further details on the project, please have a look at the wiki.
A special thanks to Bryce Harrington and Martin Pitt whose feedback on the parser was extremely important.
Nice! I can’t wait to see this happen… especially if it will make my 4 screen setup easier 🙂
dan
Would… you be willing to accept UI design changes?
Because… a table in a text file and a table in a GUI are petty much the same. Just because the table is in a gui it doesn’t make it a lot more user-friendly. (I just can’t really believe it that this was done)
Vadim: what do you suggest then?
I knew a separate xorg.conf parser was needed, but I was worried this would happen. Albert, can you please explain why a grammar file and parser generator wasn’t used? I realize they’re not easy to learn but there are massive dividends in having something easily translatable into a language of your choice, and having a reference grammar that other developers can quickly see and evaluate for correctness.
From what I can tell of the Python code, the grammar is all implicit in the code, and the “easy to extend” really means “easy once you know how the whole code works”. I hope your mentors can help convince you that something like ANTLR would be worthwhile, and are willing to help out there.
albertomilone: less use of tables, but instead use tooltips, and other various widgets that would help a lot to clean it up. I’d be gladly willing to help on the design if you’re interested – contact me by email if so.
jldugger:
What we had is Guidance’s parser which, as far as I now, is deprecated. I had already written a minimal parser for EnvyNG therefore I thought I would correct it and extend it.
I don’t know ANTLR but currently I have something which works and can replace Guidance’s xorgconfig.py. Currently both phase 1 and phase 2 rely on X-Kit therefore throwing X-Kit away at this point would not be convenient.
As regards the parser being “easy once you know how the whole code works”, it’s all documented and examples are provided with the source tarball but of course studying how the program works is still necessary.
Vadim: email sent 😉
Fine, but how big of a test set do you have for the parser? There’s a large body of configurations out there and it seems reasonable to support all valid ones.
Surely there’s a tool out there to scan LP for xorg.conf attachments.
This might be the way to fix a long standing usability issue for me: disabling/enabling the “emulate 3 button mouse” option requires manually editing xorg.conf. It should be a simple checkbox in the Mouse preferences dialog.
Though, as it is, we’ll be requiring the user to restart X when they make this change even with an x.org frontend…
jldugger: Bryce told me that he knows someone who could do the query (in launchpad) for me so as to extract as many xorg.conf as possible.
An Xorg-Editor is available: Xorg-Edit
May it needs an update and is a little bit outdated:
http://www.deesaster.org/progxorg.php
Sounds good!
Hope you meant to say QT GUI for KDE 😛
Dread Knight: no, I meant KDE4. There pyQT4 is different from pyKDE4.
One word: *augeas*. Google it, then write a lenser for augeas. Try not to duplicate functionality.
Rudd-O: Three words: read comment 6
Bart: yes, I was aware of its existence, thanks for the link.
Hi!
Will displayconfig-gtk be replaced by X-kit in future bullet-proof-x implementation?
Hi ,
I installed xorg-options-editor-gtk in jaunty 9.04 via apt.it crashed with below trace.what went wrong?
—
Traceback (most recent call last):
File “/usr/bin/xorg-options-editor-gtk”, line 12, in
xorg = XorgOptionsEditor.XorgOptionsEditorGtk.XorgOptionsEditor()
File “/usr/lib/python2.6/dist-packages/XorgOptionsEditor/XorgOptionsEditorGtk.py”, line 208, in __init__
self.xorg = xorgabstraction.XorgAbstraction(xorgSource, xorgDestination)
File “/usr/lib/python2.6/dist-packages/XorgOptionsEditor/xorgabstraction.py”, line 96, in __init__
self.getAllDrivers()
File “/usr/lib/python2.6/dist-packages/XorgOptionsEditor/xorgabstraction.py”, line 140, in getAllDrivers
files = os.listdir(aliasesPath)
OSError: [Errno 2] No such file or directory: ‘/usr/share/xserver-xorg/pci/
—