From me at the-compiler.org  Mon Sep  5 10:27:08 2016
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 5 Sep 2016 10:27:08 +0200
Subject: [qutebrowser] How to run a userscript in Windows
In-Reply-To: <95ad0d15-d6b9-ef64-40a2-2e46bb4ac47a@bigpond.com>
References: <44030f13-2295-eb90-9755-0887b7d446dd@bigpond.com>
 <4f552abe-3d12-f895-a309-2687375806b5@bigpond.com>
 <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
 <20160831210859.ckbwq2zkddn6t7fd@tonks>
 <95ad0d15-d6b9-ef64-40a2-2e46bb4ac47a@bigpond.com>
Message-ID: <20160905082707.ekmnw5bpksuho4na@tonks>

Hey,

I re-added the mailinglist in your reply, as you wrote to me directly
;)

* David Nebauer <davidnebauer3 at bigpond.com> [2016-09-03 00:19:17 +0930]:
> > * Daniel Schadt <daniel at kingdread.de> [2016-08-31 22:36:47 +0200]:
> > > > command called: spawn ['--userscript', 'SCRIPT.py']
> > > So as far as I can tell, the only things you can run on
> > > Windows as (user)script are native .exe and .bat/.cmd files.
> > > 
> > > So to solve this, you can either use
> > >      "\path\to\python.exe \path\to\script.py"
> > > as command for spawn (without the --userscript flag), or you can write
> > > a simple .bat file that just calls your real userscript under the hood.
> 
> I tried using bat/cmd userscripts as wrappers that call the python script
> but nothing worked, so I tried the simplest possible case -- 'hello.bat' in
> the userscript directory containing a single line:
> 
>         Echo message-info "Hello from a userscript!" >> "%QUTE_FIFO%"
> 
> Calling userscript hello or hello.bat resulted in the same failure I
> reported for the python script. Here are the log messages for one example:

Hmm, that's odd. Can you open an issue at
https://github.com/The-Compiler/qutebrowser so I can take a look at it
whenever I next feel like dealing with Windows stuff? ;)
> 
>     command called: spawn ['--userscript', 'hello.bat']
> [...]
>     Userscript to run:
> C:\Users\ME\AppData\Local\qutebrowser\data\userscripts\hello.bat

I'm guessing the hello.bat is in that location?

>     Error while spawning userscript: The process failed to start.

Unfortunately that's all Qt (and probably the Windows API) can give
us... It usually means the file is not at that location, or not
executable.

> It's not a quoting problem; running the bat file from a dos prompt worked
> fine if I first set QUTE_FIFO to a dummy file name. It created a file
> containing the correctly quoted command:
> 
>         message-info "Hello from a userscript!"
> 
> So now I'm wondering if the userscript mechanism works at all in windows.
> Has anyone ever run a userscript in windows successfully? If so, can someone
> post an example? If I start with something that works I may be able to build
> it up to run my python script.
> 
> Please note, it's not enough to simply execute a bat/cmd/exe file; it has to
> execute in an environment where the userscript variables (QUTE_FIFO, etc.)
> are available to the userscript.

FWIW the qutebrowser testsuite doesn't run an userscript on Windows,
but I don't remember why that was.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160905/ace36d4c/attachment.asc>

From daniel at kingdread.de  Tue Sep  6 01:13:57 2016
From: daniel at kingdread.de (Daniel Schadt)
Date: Tue, 6 Sep 2016 01:13:57 +0200
Subject: [qutebrowser] How to run a userscript in Windows
In-Reply-To: <20160905082707.ekmnw5bpksuho4na@tonks>
References: <44030f13-2295-eb90-9755-0887b7d446dd@bigpond.com>
 <4f552abe-3d12-f895-a309-2687375806b5@bigpond.com>
 <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
 <20160831210859.ckbwq2zkddn6t7fd@tonks>
 <95ad0d15-d6b9-ef64-40a2-2e46bb4ac47a@bigpond.com>
 <20160905082707.ekmnw5bpksuho4na@tonks>
Message-ID: <27ea5af1-398a-72e9-32cf-df2dbb0dc9f1@kingdread.de>

This one works for me:

    C:\Users\Daniel\AppData\Local\qutebrowser\data\userscripts\test.bat
    ----
    echo ":message-info Test" >> %QUTE_FIFO%

Running  :spawn --userscript test.bat  correctly shows "Test" as a message.
However, I had to apply a patch to get it to work. The current
implementation
seems to suffer from the same problem that :open-editor once had[1]: The
"FIFO"
file it creates is being held open by qutebrowser, which means that (on
Windows)
other processes can't write to it (stuff like commands) (patch at the
end of the
email).

Unfortunately though, it seems like this is not the cause of your problem. A
failing userscript gives the message "userscript exited with status 1", not
"userscript failed to start". Also, I've tested starting .bat files with
QProcess and the CreateProcess C call, and it worked, so the issue seems
to be
something different, and probably hard to debug, as I can't seem to
reproduce it
on my machine.

What should definitely work is to copy C:\Windows\system32\notepad.exe
to your
userscript directory and then  :spawn --userscript notepad.exe. You
could try
that just for fun, it should open an empty notepad window. If you don't
want to
copy notepad, you can also try
    :spawn --userscript 'C:\Windows\system32\notepad.exe'
and see if an error occurs.

Daniel

[1]: https://github.com/The-Compiler/qutebrowser/issues/1767

Patch:

diff --git a/qutebrowser/commands/userscripts.py
b/qutebrowser/commands/userscripts.py
index 0a8b195..65af026 100644
--- a/qutebrowser/commands/userscripts.py
+++ b/qutebrowser/commands/userscripts.py
@@ -280,14 +280,10 @@ class _WindowsUserscriptRunner(_BaseUserscriptRunner):

     This also means the userscript *has* to use >> (append) rather than >
     (overwrite) to write to the file!
-
-    Attributes:
-        _oshandle: The oshandle of the temp file.
     """

     def __init__(self, win_id, parent=None):
         super().__init__(win_id, parent)
-        self._oshandle = None

     def _cleanup(self):
         """Clean up temporary files after the userscript finished."""
@@ -301,12 +297,7 @@ class _WindowsUserscriptRunner(_BaseUserscriptRunner):
         except OSError:
             log.procs.exception("Failed to read command file!")

-        try:
-            os.close(self._oshandle)
-        except OSError:
-            log.procs.exception("Failed to close file handle!")
         super()._cleanup()
-        self._oshandle = None
         self.finished.emit()

     @pyqtSlot()
@@ -323,7 +314,9 @@ class _WindowsUserscriptRunner(_BaseUserscriptRunner):
         self._kwargs = kwargs

         try:
-            self._oshandle, self._filepath = tempfile.mkstemp(text=True)
+            handle = tempfile.NamedTemporaryFile(delete=False)
+            handle.close()
+            self._filepath = handle.name
         except OSError as e:
             message.error(self._win_id, "Error while creating tempfile: "
                                         "{}".format(e))



From me at the-compiler.org  Tue Sep  6 15:27:39 2016
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 6 Sep 2016 15:27:39 +0200
Subject: [qutebrowser] How to run a userscript in Windows
In-Reply-To: <27ea5af1-398a-72e9-32cf-df2dbb0dc9f1@kingdread.de>
References: <44030f13-2295-eb90-9755-0887b7d446dd@bigpond.com>
 <4f552abe-3d12-f895-a309-2687375806b5@bigpond.com>
 <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
 <20160831210859.ckbwq2zkddn6t7fd@tonks>
 <95ad0d15-d6b9-ef64-40a2-2e46bb4ac47a@bigpond.com>
 <20160905082707.ekmnw5bpksuho4na@tonks>
 <27ea5af1-398a-72e9-32cf-df2dbb0dc9f1@kingdread.de>
Message-ID: <20160906132739.wahjlh3mqvhe5ujd@tonks>

Hey,

* Daniel Schadt <daniel at kingdread.de> [2016-09-06 01:13:57 +0200]:
> However, I had to apply a patch to get it to work. The current
> implementation seems to suffer from the same problem that
> :open-editor once had[1]: The "FIFO" file it creates is being held
> open by qutebrowser, which means that (on Windows) other processes
> can't write to it (stuff like commands) (patch at the end of the
> email).

Do you plan to open a PR, or should I apply that patch?

> Unfortunately though, it seems like this is not the cause of your problem. A
> failing userscript gives the message "userscript exited with status 1", not
> "userscript failed to start".

Right - that message means the process didn't start at all.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160906/6a31396f/attachment.asc>

From panshulgarg at gmail.com  Wed Sep  7 23:36:35 2016
From: panshulgarg at gmail.com (Panshul Garg)
Date: Thu, 8 Sep 2016 03:06:35 +0530
Subject: [qutebrowser] Contribute to Qute Browser
Message-ID: <CA+YDQ6y18Gjnd_cJtmv8Dm8fi0MYdZfd1samABc4veeWtw6FQw@mail.gmail.com>

Hello,

I want to contribute to this project. I am really interested to contribute.
I have some experience in coding in python. Please assign me something on
which I can work.



*Regards,*

*Panshul Garg*
*3rd Year U**ndergraduate** Student*
*B.E. Computer Science*
*BITS Pilani K.K. Birla Goa Campus, Goa, India*
*panshulgarg at gmail.com <rishab.markand at gmail.com> *
*Contact : **+919675551444*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160908/58740a1d/attachment.htm>

From me at the-compiler.org  Thu Sep  8 18:28:45 2016
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 8 Sep 2016 18:28:45 +0200
Subject: [qutebrowser] Contribute to Qute Browser
In-Reply-To: <CA+YDQ6y18Gjnd_cJtmv8Dm8fi0MYdZfd1samABc4veeWtw6FQw@mail.gmail.com>
References: <CA+YDQ6y18Gjnd_cJtmv8Dm8fi0MYdZfd1samABc4veeWtw6FQw@mail.gmail.com>
Message-ID: <20160908162844.gedppxqpgus4kb36@tonks>

Hey,

* Panshul Garg <panshulgarg at gmail.com> [2016-09-08 03:06:35 +0530]:
> I want to contribute to this project. I am really interested to contribute.
> I have some experience in coding in python. Please assign me something on
> which I can work.

In the qutebrowser bugtracker, there are various issues tagged "easy",
I'd recommend starting with one of those:
https://github.com/The-Compiler/qutebrowser/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Aeasy%20-label%3A%22work%20in%20progress%22%20

Other than that, I can also always use some help in writing unit-tests
and end-to-end testcases, and there are various low-hanging fruit
there: https://github.com/The-Compiler/qutebrowser/issues/666

I hope that helps - let me know if you get stuck somewhere and need
help!

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160908/56230283/attachment.asc>

From davidnebauer3 at bigpond.com  Sun Sep 11 05:20:00 2016
From: davidnebauer3 at bigpond.com (David Nebauer)
Date: Sun, 11 Sep 2016 12:50:00 +0930
Subject: [qutebrowser] How to run a userscript in Windows
In-Reply-To: <20160905082707.ekmnw5bpksuho4na@tonks>
References: <44030f13-2295-eb90-9755-0887b7d446dd@bigpond.com>
 <4f552abe-3d12-f895-a309-2687375806b5@bigpond.com>
 <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
 <20160831210859.ckbwq2zkddn6t7fd@tonks>
 <95ad0d15-d6b9-ef64-40a2-2e46bb4ac47a@bigpond.com>
 <20160905082707.ekmnw5bpksuho4na@tonks>
Message-ID: <bdf7716d-e38b-c62b-183b-5985536d7dcb@bigpond.com>

>
>>      command called: spawn ['--userscript', 'hello.bat']
>> [...]
>>      Userscript to run:
>> C:\Users\ME\AppData\Local\qutebrowser\data\userscripts\hello.bat
> I'm guessing the hello.bat is in that location?

Well, no, as it turns out. The bat file was in:

	C:\Users\ME\AppData\Local\qutebrowser\userscripts\hello.bat


That is, not in the 'qutebrowser\data\userscripts' subdirectory but in 
'qutebrowser\userscripts' (note missing 'data' subdirectory).

Once I moved the bat file into the correct directory, qutebrowser was 
able to run it. The script then produced the qutebrowser log messages:

Userscript exited with status 1
     [...]
Process stdout:
     C:\Windows\system32>Echo ":message-info Test" 
1>>"C:\Users\ME\AppData\Local\Temp\tmp_y_rdd1a"
     Process stderr:
     The process cannot access the file because it is being used by 
another process.

I presume this is the "readonly FIFO" problem Kingdread documents in 
pull request #1927 <https://github.com/The-Compiler/qutebrowser/pull/1927>.

Note: I was able to run my python script from a userscript batch file 
containing a command like:

START /I "Run userscript" py C:\Users\ME\PATH\TO\PYTHON\SCRIPT.py %*

The python script successfully accessed and used QUTE_URL and other 
qutebrowser environmental variables. The python script was supposed to 
send feedback to qutebrowser using QUTE_FIFO but did not, presumably due 
to the FIFO bug. But it was otherwise a success.

So, my userscripts are running on windows now, and once the FIFO bug fix 
is incorporated into a windows release I'll be able to display script 
feedback in qutebrowser.

Sorry for wasting your time and Daniel's time. Still, it did point the 
way to the FIFO bug...

One thing would have helped me and you might consider implementing it: 
I'd have quickly known the cause of the problem if qutebrowser checked 
for the existence of a userscript before attempting to execute it and, 
in the event it is not found, gave a specific "userscript not found in 
<userscript directory path goes here>" message. I'll add a feature 
request for this.

Thanks for your help and for a great browser.


From me at the-compiler.org  Sun Sep 11 16:48:58 2016
From: me at the-compiler.org (Florian Bruhin)
Date: Sun, 11 Sep 2016 16:48:58 +0200
Subject: [qutebrowser] How to run a userscript in Windows
In-Reply-To: <bdf7716d-e38b-c62b-183b-5985536d7dcb@bigpond.com>
References: <44030f13-2295-eb90-9755-0887b7d446dd@bigpond.com>
 <4f552abe-3d12-f895-a309-2687375806b5@bigpond.com>
 <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
 <20160831210859.ckbwq2zkddn6t7fd@tonks>
 <95ad0d15-d6b9-ef64-40a2-2e46bb4ac47a@bigpond.com>
 <20160905082707.ekmnw5bpksuho4na@tonks>
 <bdf7716d-e38b-c62b-183b-5985536d7dcb@bigpond.com>
Message-ID: <20160911144857.ybjezvyf2hokjc77@tonks>

Hey,

* David Nebauer <davidnebauer3 at bigpond.com> [2016-09-11 12:50:00 +0930]:
> > 
> > >      command called: spawn ['--userscript', 'hello.bat']
> > > [...]
> > >      Userscript to run:
> > > C:\Users\ME\AppData\Local\qutebrowser\data\userscripts\hello.bat
> > I'm guessing the hello.bat is in that location?
> 
> Well, no, as it turns out. The bat file was in:
> 
> 	C:\Users\ME\AppData\Local\qutebrowser\userscripts\hello.bat
> 
> 
> That is, not in the 'qutebrowser\data\userscripts' subdirectory but in
> 'qutebrowser\userscripts' (note missing 'data' subdirectory).
> 
> Once I moved the bat file into the correct directory, qutebrowser was able
> to run it. The script then produced the qutebrowser log messages:
> 
> Userscript exited with status 1
>     [...]
> Process stdout:
>     C:\Windows\system32>Echo ":message-info Test"
> 1>>"C:\Users\ME\AppData\Local\Temp\tmp_y_rdd1a"
>     Process stderr:
>     The process cannot access the file because it is being used by another
> process.
> 
> I presume this is the "readonly FIFO" problem Kingdread documents in pull
> request #1927 <https://github.com/The-Compiler/qutebrowser/pull/1927>.

This was now merged, and will be in the next release which will
hopefully happen somewhen over the next few weeks. Unfortunately there
are still some kinks we need to figure out before that...

> Sorry for wasting your time and Daniel's time. Still, it did point the way
> to the FIFO bug...

No worries! :)

> One thing would have helped me and you might consider implementing it: I'd
> have quickly known the cause of the problem if qutebrowser checked for the
> existence of a userscript before attempting to execute it and, in the event
> it is not found, gave a specific "userscript not found in <userscript
> directory path goes here>" message. I'll add a feature request for this.

That sounds like a great idea, and should be quite easy to do.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160911/40b24bab/attachment.asc>

From davidnebauer3 at bigpond.com  Tue Sep 13 16:35:26 2016
From: davidnebauer3 at bigpond.com (David Nebauer)
Date: Wed, 14 Sep 2016 00:05:26 +0930
Subject: [qutebrowser] How to run a userscript in Windows
In-Reply-To: <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
References: <44030f13-2295-eb90-9755-0887b7d446dd@bigpond.com>
 <4f552abe-3d12-f895-a309-2687375806b5@bigpond.com>
 <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
Message-ID: <b2ac375e-7618-cdcf-1879-16b08c993543@bigpond.com>

On 01/09/16 06:06, Daniel Schadt wrote:
>
> So as far as I can tell, the only things you can run on
> Windows as (user)script are native .exe and .bat/.cmd files.
>
FWIW, after using the correct userscripts directory and successfully 
running bat and cmd userscripts, I can confirm that I was unable to 
successfully execute a python userscript. This was the case even though 
my system is set up to run python scripts directly from the command line 
without explicitly invoking the interpreter (using file association).

I suggest the userscript documentation should include the information 
that on Windows only com and bat (and exe) files can be used as userscripts.

David.


From davidnebauer3 at bigpond.com  Tue Sep 13 16:45:36 2016
From: davidnebauer3 at bigpond.com (David Nebauer)
Date: Wed, 14 Sep 2016 00:15:36 +0930
Subject: [qutebrowser] How to run a userscript in Windows
In-Reply-To: <bdf7716d-e38b-c62b-183b-5985536d7dcb@bigpond.com>
References: <44030f13-2295-eb90-9755-0887b7d446dd@bigpond.com>
 <4f552abe-3d12-f895-a309-2687375806b5@bigpond.com>
 <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
 <20160831210859.ckbwq2zkddn6t7fd@tonks>
 <95ad0d15-d6b9-ef64-40a2-2e46bb4ac47a@bigpond.com>
 <20160905082707.ekmnw5bpksuho4na@tonks>
 <bdf7716d-e38b-c62b-183b-5985536d7dcb@bigpond.com>
Message-ID: <231230e3-2352-4b26-61f2-be47ab2dffd5@bigpond.com>

On 11/09/16 12:50, David Nebauer wrote:
>>
>>>      command called: spawn ['--userscript', 'hello.bat']
>>> [...]
>>>      Userscript to run:
>>> C:\Users\ME\AppData\Local\qutebrowser\data\userscripts\hello.bat
>> I'm guessing the hello.bat is in that location?
>
> Well, no, as it turns out. The bat file was in:
>
>     C:\Users\ME\AppData\Local\qutebrowser\userscripts\hello.bat 

Might be worth mentioning that I used the wrong userscript directory 
because I misunderstood the documentation. It says userscripts need to 
be, "stored in your data directory under 'userscripts'". On the Windows 
platform I took "data directory" to be a reference to qutebrowser's 
install location under "AppData/Local" and formed the rest of the path 
based on the unix userscript path (which does not include the 'data' 
subdirectory).

I suggest the documentation could explicitly state the Windows 
userscript path. Even better would be if 'qute:version' output included 
the full userscripts directory ||path, in the same way that it currently 
includes the "Desktop" path in unix and "Imported from" path in Windows. 
That way the information would be available on every platform 
qutebrowser runs on.

David.


From me at the-compiler.org  Wed Sep 14 07:08:36 2016
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 14 Sep 2016 07:08:36 +0200
Subject: [qutebrowser] How to run a userscript in Windows
In-Reply-To: <231230e3-2352-4b26-61f2-be47ab2dffd5@bigpond.com>
References: <44030f13-2295-eb90-9755-0887b7d446dd@bigpond.com>
 <4f552abe-3d12-f895-a309-2687375806b5@bigpond.com>
 <3d3fba81-7a6e-45a8-a6e7-68d9e40b34da@kingdread.de>
 <20160831210859.ckbwq2zkddn6t7fd@tonks>
 <95ad0d15-d6b9-ef64-40a2-2e46bb4ac47a@bigpond.com>
 <20160905082707.ekmnw5bpksuho4na@tonks>
 <bdf7716d-e38b-c62b-183b-5985536d7dcb@bigpond.com>
 <231230e3-2352-4b26-61f2-be47ab2dffd5@bigpond.com>
Message-ID: <20160914050836.dx33ug5dk3pvooyx@tonks>

* David Nebauer <davidnebauer3 at bigpond.com> [2016-09-14 00:15:36 +0930]:
> On 11/09/16 12:50, David Nebauer wrote:
> > > 
> > > >      command called: spawn ['--userscript', 'hello.bat']
> > > > [...]
> > > >      Userscript to run:
> > > > C:\Users\ME\AppData\Local\qutebrowser\data\userscripts\hello.bat
> > > I'm guessing the hello.bat is in that location?
> > 
> > Well, no, as it turns out. The bat file was in:
> > 
> >     C:\Users\ME\AppData\Local\qutebrowser\userscripts\hello.bat
> 
> Might be worth mentioning that I used the wrong userscript directory because
> I misunderstood the documentation. It says userscripts need to be, "stored
> in your data directory under 'userscripts'". On the Windows platform I took
> "data directory" to be a reference to qutebrowser's install location under
> "AppData/Local" and formed the rest of the path based on the unix userscript
> path (which does not include the 'data' subdirectory).

That's because the XDG standard (which is at least commonly used on
Linux) has separate paths for config (~/.config) and data
(~/.local/share), while Windows doesn't - so on Windows, we simply
have separate data/ and cache/ subdirs in there.

> I suggest the documentation could explicitly state the Windows userscript
> path. Even better would be if 'qute:version' output included the full
> userscripts directory ||path, in the same way that it currently includes the
> "Desktop" path in unix and "Imported from" path in Windows. That way the
> information would be available on every platform qutebrowser runs on.

Just a small clarifiction: That's not the desktop path, that's what
desktop environment the user is using (i.e., the DESKTOP_SESSION
environment variable).

I agree it'd make sense to display at least the
config/data/runtime/cache directories in qute:version though.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160914/db11db2c/attachment.asc>

From blm at zedat.fu-berlin.de  Thu Sep 22 09:36:32 2016
From: blm at zedat.fu-berlin.de (Brent Moran)
Date: Thu, 22 Sep 2016 09:36:32 +0200
Subject: [qutebrowser] Outputting all non-default config options
Message-ID: <20160922073632.GA15821@linuxinc.localdomain>

Is there any way to output differences between my config file and the
defaults all at once?  I fear I've broken something, since some pages
are rendering oddly.  See attached .png.  Most, however, seem fine.

Brent
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qutebrowser.png
Type: image/png
Size: 419139 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160922/1cd3ee9c/attachment.png>

From me at the-compiler.org  Thu Sep 22 14:45:30 2016
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 22 Sep 2016 14:45:30 +0200
Subject: [qutebrowser] Outputting all non-default config options
In-Reply-To: <20160922073632.GA15821@linuxinc.localdomain>
References: <20160922073632.GA15821@linuxinc.localdomain>
Message-ID: <20160922124530.du3eith7zafswxh3@tonks>

Hey Brent,

* Brent Moran <blm at zedat.fu-berlin.de> [2016-09-22 09:36:32 +0200]:
> Is there any way to output differences between my config file and the
> defaults all at once?  I fear I've broken something, since some pages
> are rendering oddly.  See attached .png.  Most, however, seem fine.

There isn't really an official way, but if you do :report and show the
debug log (instead of sending it), it'll have the changed config
options.

Another useful debugging tool is to start qutebrowser with
--temp-basedir which makes it start with a vanilla config/state/cache.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160922/1f318ff4/attachment.asc>

From ryan at rcorre.net  Thu Sep 22 19:11:21 2016
From: ryan at rcorre.net (Ryan Roden-Corrent)
Date: Thu, 22 Sep 2016 13:11:21 -0400
Subject: [qutebrowser] Outputting all non-default config options
In-Reply-To: <20160922124530.du3eith7zafswxh3@tonks>
References: <20160922073632.GA15821@linuxinc.localdomain>
 <20160922124530.du3eith7zafswxh3@tonks>
Message-ID: <ED6E193D-A580-4653-ABF2-0A52E08182A6@rcorre.net>

>Another useful debugging tool is to start qutebrowser with
>--temp-basedir which makes it start with a vanilla config/state/cache.

After which you could diff the vanilla config against your real config.
- Ryan

On September 22, 2016 8:45:30 AM EDT, Florian Bruhin <me at the-compiler.org> wrote:
>Hey Brent,
>
>* Brent Moran <blm at zedat.fu-berlin.de> [2016-09-22 09:36:32 +0200]:
>> Is there any way to output differences between my config file and the
>> defaults all at once?  I fear I've broken something, since some pages
>> are rendering oddly.  See attached .png.  Most, however, seem fine.
>
>There isn't really an official way, but if you do :report and show the
>debug log (instead of sending it), it'll have the changed config
>options.
>
>Another useful debugging tool is to start qutebrowser with
>--temp-basedir which makes it start with a vanilla config/state/cache.
>
>Florian



From ryan at rcorre.net  Mon Sep 26 01:26:30 2016
From: ryan at rcorre.net (Ryan Roden-Corrent)
Date: Sun, 25 Sep 2016 19:26:30 -0400
Subject: [qutebrowser] xvfb/opengl error running tests
Message-ID: <20160925232630.GA1754@desktop-arch.localdomain>

Tests are failing on my machine due to the following warning:

    QtWarningMsg: QXcbIntegration: Cannot create platform OpenGL context,
    neither GLX nor EGL are enabled

This only happens on my desktop with an Nvidia card, my laptop with integrated
graphics is fine. Has anyone else seen this? Is there a way to make the tests
ignore a particular warning?

It works fine if I don't use xvfb, but that gets kind of annoying.

-Ryan


From ryan at rcorre.net  Mon Sep 26 02:30:54 2016
From: ryan at rcorre.net (Ryan Roden-Corrent)
Date: Sun, 25 Sep 2016 20:30:54 -0400
Subject: [qutebrowser] xvfb/opengl error running tests
In-Reply-To: <20160925232630.GA1754@desktop-arch.localdomain>
References: <20160925232630.GA1754@desktop-arch.localdomain>
Message-ID: <20160926003054.GA12897@desktop-arch.localdomain>

Related question: how can I pass CLI args to the test process?

One workaround I've found is to set --qt-name=qutebrowser-test and add a window
manager rule that puts all "qutebrowser-test" windows on an unused workspace.
However, I just hacked this into _default_args because I wasn't sure how to pass
an arg as a CLI argument.

-Ryan

On Sun 09/25/16 07:26PM, Ryan Roden-Corrent wrote:
> Tests are failing on my machine due to the following warning:
> 
>     QtWarningMsg: QXcbIntegration: Cannot create platform OpenGL context,
>     neither GLX nor EGL are enabled
> 
> This only happens on my desktop with an Nvidia card, my laptop with integrated
> graphics is fine. Has anyone else seen this? Is there a way to make the tests
> ignore a particular warning?
> 
> It works fine if I don't use xvfb, but that gets kind of annoying.
> 
> -Ryan


From me at the-compiler.org  Mon Sep 26 08:08:15 2016
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 26 Sep 2016 08:08:15 +0200
Subject: [qutebrowser] xvfb/opengl error running tests
In-Reply-To: <20160926003054.GA12897@desktop-arch.localdomain>
 <20160925232630.GA1754@desktop-arch.localdomain>
Message-ID: <20160926060815.vrqmgydpieieatsh@tonks>

Hey Ryan,

* Ryan Roden-Corrent <ryan at rcorre.net> [2016-09-25 19:26:30 -0400]:
> Tests are failing on my machine due to the following warning:
> 
>     QtWarningMsg: QXcbIntegration: Cannot create platform OpenGL context,
>     neither GLX nor EGL are enabled
> 
> This only happens on my desktop with an Nvidia card, my laptop with integrated
> graphics is fine. Has anyone else seen this? Is there a way to make the tests
> ignore a particular warning?
> 
> It works fine if I don't use xvfb, but that gets kind of annoying.

Yeah, someone else reported the same as well:
https://github.com/The-Compiler/qutebrowser/issues/1819

You can probably make it work by installing mesa-libgl but that'll
conflict with nvidia-libgl :-/

This change in Qt *might* help:
https://codereview.qt-project.org/#/c/167643/
...but for some reason it's been abandoned.

* Ryan Roden-Corrent <ryan at rcorre.net> [2016-09-25 20:30:54 -0400]:
> Related question: how can I pass CLI args to the test process?

You currently can't. I opened
https://github.com/The-Compiler/qutebrowser/issues/1976 for it, as it
sounds useful indeed.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20160926/90993740/attachment.asc>