From jordi@amospalla.es Thu Apr 10 15:55:03 2014 Received: (at 402) by bugs.x2go.org; 10 Apr 2014 13:55:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,URIBL_BLOCKED autolearn=ham version=3.3.2 X-Greylist: delayed 516 seconds by postgrey-1.34 at ymir.das-netzwertkeam.de; Thu, 10 Apr 2014 15:55:03 CEST Received: from ispconfig.net1.amospalla.es (amospalla.es [188.40.66.228]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 71CBD3BC41 for <402@bugs.x2go.org>; Thu, 10 Apr 2014 15:55:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ispconfig.net1.amospalla.es (Postfix) with ESMTP id C95C51AC2049; Thu, 10 Apr 2014 15:46:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ispconfig.amospalla.es Received: from ispconfig.net1.amospalla.es ([127.0.0.1]) by localhost (ispconfig.amospalla.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kRqCAwV_wjL; Thu, 10 Apr 2014 15:46:26 +0200 (CEST) Received: from amospalla.es (localhost [IPv6:::1]) by ispconfig.net1.amospalla.es (Postfix) with ESMTP id 157A01AC107D; Thu, 10 Apr 2014 15:46:26 +0200 (CEST) Received: from 62.82.108.2 (SquirrelMail authenticated user jordi@amospalla.es) by amospalla.es with HTTP; Thu, 10 Apr 2014 15:46:26 +0200 Message-ID: In-Reply-To: <20140410112954.Horde.uCkuh3QAX7cM8yLbgqcxtQ1@mail.das-netzwerkteam.de> References: <8be4d14fda106d24b56c8cf94ec9a918.squirrel@www.amospalla.es> <20140402130029.Horde.pCv_6moTdCQfNpA2fQNFFQ1@mail.das-netzwerkteam.de> <53404130.6080903@amospalla.es> <20140405193722.Horde.TssS-w1ielZ5Dbza76YEJA1@mail.das-netzwerkteam.de> <3f8a733e7f2c8b1774c67424a4d52209.squirrel@amospalla.es> <20140410112954.Horde.uCkuh3QAX7cM8yLbgqcxtQ1@mail.das-netzwerkteam.de> Date: Thu, 10 Apr 2014 15:46:26 +0200 Subject: Re: [X2Go-Dev] Bug#402: Bug#402: Numlock issues From: jordi@amospalla.es To: "Mike Gabriel" Cc: 402@bugs.x2go.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal > Hi Jordi, > (I am re-Cc:-ing #402 in our BTS, hope that's ok...) > > > On Do 10 Apr 2014 12:03:02 CEST, jordi wrote: > >>> Hi Jordi, >>> >>> On Sa 05 Apr 2014 19:45:20 CEST, Jordi Marqués wrote: >>> >>>> Hello Mike, sorry for late answer. >>>> >>>> I have looked at it, so what you need is a simple bash script. I can >>>> do that. Could I write it and send it to you? >>>> >>>> If so, I think I can do it on monday. >>>> >>>> Jordi. >>> >>> Sure, send it to me. >>> >>> Make sure that X2Go session startup does not break local session >>> startup. So if you change something in pre-runcommand.d, make sure it >>> gets restored in post-runcommand.d. >> >> Hello Mike, >> >> sorry again for being late, I've got more work than I can handle. >> >> Please take a look at this post-runcommand.d >> http://paste.debian.net/92885/ >> and this pre-runcommand.d: http://paste.debian.net/92886/ . >> >> I write to files to save the state of the two settings previous to being >> modified so I can restore it. I set a folder variable where I save those >> files. Would that be a correct way to work inside X2go? I set them to >> /tmp >> to test, please modify them accordingly to what would be the best value. >> >> Not directly related to this, I've played also with the >> reduced_resources >> variable, which set to true, disables completely windows animations, and >> makes window moving be done with a classic transparent line drawn box, >> instead of the real window image. I've applied to my users, if you find >> it >> interesting to try tell me to add it. > > The approach is good. I have copied both scripts from paste.debian.net > to my local working copy of x2gomatebindings. Thanks! > > However, one thought: > > With your proposed approach, the dconf/gsettings setup remains > X2Go'ish for the duration of the X2Go Session. > It would be good, to make those settings and remove them immediately, > after the session has successfully come up. I am not sure how MATE > will behave if you launch the post-runcommand script 20 minutes after > the session has come up. > > And another thought... > > Another approach actually is... Talking to MATE upstream and asking > them to patch their code directly (i.e. ignore those settings / use > pre-set value if MATE runs inside an X2Go session). I will talk to > Stefano & co. about that (who is MATE upstream). I don't really know if these settings are session aware, but my impression is that those are global settings for a user. If they are not and I can modify the script please let me know!