[ubuntu-x] A few updates on X-Kit

[Bryce Harrington]

On Mon, Jun 09, 2008 at 09:54:11AM +0200, Alberto Milone wrote:
> A few updates on X-Kit:
> 
> 1) I have written a script which parser the man page of xorg.conf and
> writes an xml file (see the attached xml file). I have also written a
> small parser which puts the content of the xml into a gtk GUI. Here's a
> screenshot:
> http://www.albertomilone.com/xkit3.png

Sweet, you're making swift progress.

The gui mockup does accurately reflect what we talked about at UDS,
however in looking at it, I notice a few problems:

1.  The horizontal scrollbar to be able to read the description looks
    quite bad.  I'm not sure what the solution is though since screen
    real estate is limited, but we ought to think more on this.  Perhaps
    the descriptions could be placed on a second line, like is done in
    the Services Settings dialog?

2.  I know I was the one that suggested the checkboxes, but in looking
    at the mockup with all the drivers, it seems rather cumbersome.  I'm
    wondering if perhaps a better style would be to show just the "in
    use" options, with Add/Remove buttons that pop up a separate dialog
    with the list of all options, sort of like the User Settings dialog
    or the Authentication tab on Software Sources.

3.  With the driver dropdown, I'm wondering if we could place it down in
    the table with the options.  We'd need the value column to support
    dropdown selection though - which might not be available.

> I'm not sure as to how I could get the default values for each option in
> xorg.conf though. For example currently I get the type of the value
> which an option can be assigned from the example e.g. Option "OffTime"
> "time", however I don't know how I can make the program understand that,
> for example, "time" is a number and not a boolean or a string. We might
> get around this by avoiding to set a default value.

Yeah, we may be able to bypass this issue if we went with the UI style
described in issue #2.  The secondary dialog would list the options and
descriptions, but not the type.  Then when the user chooses to add one
of the items, they'll be required to put in a type-appropriate value.

Worst case, if we definitely need the default values, these can be
parsed out of the xserver source code, although it might be tricky.  I
was looking at the ServerFlags stuff earlier today and notice that the
defaults are set by instantiating a struct, but without directly
referencing the fields.

> 2) Yesterday I updated the xorg parser since I hadn't foreseen the case
> in which an option was there without an (explicitly) assigned value e.g.
> Option "AddARGBGLXVisuals", and now the value of such options is
> interpreted as "True".
> 
> 
> 3) One thing which I don't understand yet is what the deadline for
> launchpad specs means. Does it mean that it's too late for my spec to be
> approved for Intrepid?

No; I spoke with Colin about it at the Platform team meeting today, and
he'll review and approve once he gets a chance.  He's been out for the
last week so approvals are running a tad late anyway.

> 4) As regards the Screen Resolution GUI (for phase 1 of the spec) I
> think it can be implemented in the following way:
> 
>   a) the main program will check the resolution and the multi-head
> layout so that, for example, if a user selects 1600x1200 left-of
> 1024x768, the program will do something like this (in pseudocode) to
> calculate the required framebuffer size (x, y):
> if left-of or right-of: x = x1 + x2; y = y1 > y2 ? y1 : y2;
> elseif if above or below: x = x1 > x2 ? x1 : x2; y = y1 + y2;
> 
>   b) then it would compare the result with the size of the available
> framebuffer (which you can get with "xrandr -q" from the command line)
> and if the size of framebuffer is not enough to contain both screens
> then the program will show a dialog with an "unlock" button (from
> PolicyKit) asking to change the Virtual option and if the Apply button
> is pressed then the program will call my script (which in turn will use
> my parser and the validator) by passing it the new size as an argument.
> 
> I think that point a) and b) should be implemented in C in the main
> program (and it should be trivial to do so, apart from the PolicyKit
> part perhaps), while X-Kit will only be called when needed i.e. when the
> Apply button of that dialog is clicked.

Cool, thanks.  I'll plan on looking into doing this coding when I get
a decent chunk of time.

> 5) I'll start working on the validator soon, therefore having the API
> of the xorgparser reviewed ASAP (by you, Michael and/or Martin) would be
> nice (I know that you're very busy with other stuff), since if you
> wanted me to change the API of the parser, I would have to rewrite the
> validator once it's ready.

Sure, here are my review comments on the xorgparser code:

According to the xorg.conf spec, there are three obsolete sections,
Keyboard, Pointer, and XInput.  The first two should be treated as
synonymous with InputDevice on parsing.

In one of the comments you mention 'inverted coma', by which I'm
guessing you mean 'double quote'?

There's several API calls for setting specific parameters -
DefaultDepth, ArgbGlxVisuals, Composite, etc. but all of which seem to
have fairly similar code.  I wonder if there might be a more generic way
of enabling/removing these?

One thing that might be nice for testing the parser capability would be
to search launchpad for attachments named "*xorg.conf*", and download
them.  Martin, do you know of an easy way of doing something like this
with python-launchpad-bugs or other scripty tools?

Bryce