Merge lp://staging/~fourdollars/unity-greeter/add-hidpi-support into lp://staging/unity-greeter

FAILED: Continuous integration, rev:1468
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https://code.launchpad.net/~fourdollars/unity-greeter/add-hidpi-support/+merge/244266/+edit-commit-message

http://jenkins.qa.ubuntu.com/job/unity-greeter-ci/55/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-greeter-vivid-amd64-ci/3
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-greeter-vivid-armhf-ci/3

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/unity-greeter-ci/55/rebuild

Can't this just be completed using the existing GDK API instead of using X calls?

i.e.

var use_hidpi = false;
var screen = Gdk.Screen.get_default ()
for (var i = 0; i < screen.get_n_monitors (); i++)
{
    var width_mm = screen.get_monitor_width_mm (i);
    var height_mm = screen.get_monitor_height_mm (i);
    var ppi = ...
    if (ppp ...)
        use_hidpi = true;
}

No, this step needs to be done before GDK initialized.

BTW, by the internal design of GTK+3/GDK, unity-settings-daemon/gnome-settings-daemon should be started before any GTK+3/GDK based application.
Because the xsettings plugin will bring up a property called '_XSETTINGS_SETTINGS', and every GTK+3/GDK based application will look for this property to set the proper scale factor when it starts.
This scale factor will be changed with "gsettings get org.gnome.desktop.interface scaling-factor".
The current design of unity-greeter will execute Gtk.init() or Gdk.init() before unity-settings-daemon starts, so the scale factor is already set as 1 by default because it can not find the X property '_XSETTINGS_SETTINGS'.
If we can execute unity-settings-daemon before Gtk.init()/Gdk.init() and make sure the X property '_XSETTINGS_SETTINGS' is already there, we may not need this patch.

That seems like a better solution. We should start unity-settings-daemon before we initialize GTK+ because all sorts of behaviour might change when it starts.

FAILED: Continuous integration, rev:1497
http://jenkins.qa.ubuntu.com/job/unity-greeter-ci/56/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-greeter-vivid-amd64-ci/4/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-greeter-vivid-armhf-ci/4/console

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/unity-greeter-ci/56/rebuild

Hi,

Could you help to review my revision?
I saw the failed of jenkins, but it doesn't seem relative to my change.

I don't understand the purpose of:

var builder = new StringBuilder ();
builder.append ("xwininfo -root -tree");
builder.append ("| awk '{print $1}'");
builder.append ("| grep ^0x");
builder.append ("| while read id; do xprop -id $id; done");
builder.append ("| grep _XSETTINGS_SETTINGS > /dev/null");

Why do we need to do this?

Does this obsolete https://code.launchpad.net/~woodrow-shen/unity-greeter/fix-hidpi-support/+merge/242046?

Making https://code.launchpad.net/~woodrow-shen/unity-greeter/fix-hidpi-support/+merge/242046 obsolete should be OK.
It is up to Robert.

The StringBuilder is to create commands combo to check if the xsettings plugin of unity-settings-daemon is ready or not.

> The StringBuilder is to create commands combo to check if the xsettings plugin
> of unity-settings-daemon is ready or not.

That seems really hacky - how does Unity shell tell if the xsettings plugin is active? We should use the same method,

So far as I know, Unity shell does nothing for the xsettings plugin.

Looking at unity-settings-daemon/gnome-settings-daemon/main.c

static void
name_acquired_handler (GDBusConnection *connection,
                       const gchar *name,
                       gpointer user_data)
{
        GDBusProxy *proxy;

        proxy = gnome_settings_session_get_session_proxy ();
#ifdef HAVE_IBUS
        set_legacy_ibus_env_vars (proxy);
#endif
        start_settings_manager ();
        register_with_gnome_session (proxy);
        watch_for_term_signal (manager);
}

And in unity-greeter/src/settings-daemon.vala:

[DBus (name="org.gnome.SessionManager")]
public class SessionManagerInterface : Object
{
    public bool session_is_active { get { return true; } }
    public string session_name { get { return "ubuntu"; } }
    public uint32 inhibited_actions { get { return 0; } }
}

So I think you should be able to add a register_client method and wait for "gnome-settings-daemon" to connect.

I think for Unity shell it's probably managed in gnome-session (i.e. the shell doesn't start until gnome-session has gnome-settings-daemon connect).

Even unity-settings-daemon/gnome-settings-daemon is connected, it doesn't mean the xsettings plugin is ready.
Is there any way to check if the xsettings plugin is ready directly?

I don't know of a method for this, but:
- Does this mean there's a race condition if you start a GTK+ application in Unity before the xsettings plugin is ready? And we only see this in the greeter because we start quickly?
- Do we need to wait for the plugin? Shouldn't GTK+ detect when this setting appears/changes and adjust appropriately?

- Yes, there is a race condition. We also see this issue in another bug #1382291.
- GTK+ will detect _XSETTINGS_SETTINGS in the first function call relative to the graphics. If it can not find _XSETTINGS_SETTINGS, it will use 1 as the scale factor by default when the scale factor is actually 2 in _XSETTINGS_SETTINGS.

The problem with this branch is the hack calling xwininfo from the the greeter before starting. This is risky because:
- We're calling a relatively complicated shell script from inside an executable (very hard to understand)
- We're blocking startup for this to complete (if something goes wrong we have no UI)

The changes without this hack will be accepted, then it might be easier to do a second MP to solve the race condition.

@Shih-Yuan Lee, are we sure about the "the xsettings needs to be set before GTK starts"?

I just did that test
- start a wmaker session
- run gedit
- run unity-settings-daemon
- change the scaling-factor gsettings key

gedit scaled fine, obviously it was started before having a settings manager...

(that's on vivid)

should that be rejected? the greeter correctly scale now in vivid with unity-settings-daemon

@seb128,

I believe there is some improvement for the GTK+2/GTK+3 in vivid so we may not need this in vivid.