You are not logged in.

#426 2017-02-02 18:14:22

The Compiler
Member
From: Winterthur, Switzerland
Registered: 2011-05-01
Posts: 213
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Yeah, Qt 5.8 has a ton of regressions and issues with qutebrowser. Most of them are fixed/worked around in -git, but I didn't get to fixing the rest and releasing v0.9.2 yet as I had exams until today (yay!).


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

#427 2017-02-13 12:02:38

stupidus
Member
Registered: 2012-02-27
Posts: 124

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I am trying to import my bookmarks from firefox to qutebrowser. I found this script, however, I have no idea, how to use it. First of all, it does not come installed with qutebrowser (at least not with qutebrowser-git). So, I tried to run it from a terminal, but it cannot import bs4. I assume, that is some module within qutebrowser? But I don't know where to install it or how to call this script from qutebrowser.

Offline

#428 2017-02-13 12:09:40

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,241
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

It's a python script - and quite short - you can read it to see how it's used.  You'll need  bs4.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#429 2017-02-13 13:33:14

stupidus
Member
Registered: 2012-02-27
Posts: 124

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I had looked for bs4 in the repos and in AUR, but I did not really think that the package might have a different name.
However, the script still does not work for me. Or maybe I just don't understand how to use it.
I am calling it as "./importer.py firefox bookmarks.html", with bookmarks.html being the file I exported from firefox before.
I am then getting the following error:

Traceback (most recent call last):
  File "./importer.py", line 79, in <module>
    main()
  File "./importer.py", line 34, in main
    import_netscape_bookmarks(args.bookmarks, args.bookmark_format)
  File "./importer.py", line 71, in import_netscape_bookmarks
    if tag['href'] not in bookmarks:
  File "/usr/lib/python3.6/site-packages/bs4/element.py", line 997, in __getitem__
    return self.attrs[key]
KeyError: 'href'

I then realized, that all the tags in the bookmarks.html file are in capital letters, so I modified the script accordingly. I don't get error messages anymore, but there is no output either.
Also, I don't understand, why you need to add the browser you are using as an argument for the script. It is not using that information anyway.

Offline

#430 2017-02-13 13:58:11

Docbroke
Member
From: India
Registered: 2015-06-13
Posts: 1,172

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Trilby has given link to the bs4, which leads to "python-beautifulsoup4" package in community


Arch is home!
sway rofi qutebrowser vifm vim mutt lizzy pass

Offline

#431 2017-02-13 14:10:02

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,241
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

It works fine for me on a properly formated bookmarks file.  Case of tags is irrelevant.  Can you share your bookmarks file so we can try it?  Alternatively try subsets of your bookmarks file that you can share or try the example file from here.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#432 2017-02-13 14:13:11

stupidus
Member
Registered: 2012-02-27
Posts: 124

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I figured it out. There were some RSS feeds in the bookmarks file. Because these don't have an href, it caused the error message. And as these were in the beginning of the file, the script could not do anything. So, I simply removed all the lines corresponding to RSS feeds, and it worked well. Thank you!

Offline

#433 2017-02-13 17:02:09

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I've got a few issues since the Qt 5.8 updates:

- Drop-down lists vanish instantly. (Like the 'Jump to' list at the bottom of this page.) It seems that the ephemeral list spawns a new window that closes just as instantly.

- The 'print' command returns the following error: 'Printing is unsupported with QtWebEngine on Qt < 5.8. Well, it is Qt 5.8...

Anybody experiencing the same issues?

Offline

#434 2017-02-13 17:04:47

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 29,046
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I get the print error. But drop downs are working fine (Intel card with native kernel driver).


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#435 2017-02-13 17:11:37

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,241
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

See the webengine tracking issue: printing support is incomplete.  It will work with ":print --pdf /path/to/outfile.pdf".  Otherwise I get the same error message with just ":print".

So other than the error message itself being wonky (typo maybe) it is as expected.  No problem here with dropdowns on [community]/qutebrowser or qutebrowser-git - I'm also using intel/modesetting.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#436 2017-02-13 17:22:13

ayekat
Member
Registered: 2011-01-17
Posts: 1,392
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Ambrevar wrote:

Drop-down lists vanish instantly. (Like the 'Jump to' list at the bottom of this page.) It seems that the ephemeral list spawns a new window that closes just as instantly.

I experience the same issue, but only with the WebEngine backend and only on my own homebrew¹ WM. With WebKit and/or Openbox, dropdown menus work fine.
I assume it uses an X feature not handled by all WMs (although I haven't yet investigated which one exactly).

___
¹ Read: "Badly written"


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

#437 2017-02-13 17:23:18

The Compiler
Member
From: Winterthur, Switzerland
Registered: 2011-05-01
Posts: 213
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Ambrevar wrote:

- Drop-down lists vanish instantly. (Like the 'Jump to' list at the bottom of this page.) It seems that the ephemeral list spawns a new window that closes just as instantly.

It's a Qt bug - dropdowns are "normal" windows now and thus close depending on your WM. I submitted a fix yesterday, and once it's approved and merged I'll try to get the patch into Arch's qt5-webengine package.

Ambrevar wrote:

- The 'print' command returns the following error: 'Printing is unsupported with QtWebEngine on Qt < 5.8. Well, it is Qt 5.8...

It'll work with PyQt 5.8. Arch patches PyQt to work with Qt 5.8, but apparently doesn't add new methods.


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

#438 2017-02-13 18:27:56

Ambrevar
Member
Registered: 2011-08-14
Posts: 212
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I use AwesomeWM, which might explain the different behaviours seen by other users.

What's the point of spawning a "normal" window for the dropdown?

@Trilby: thanks for the --pdf tip!

Offline

#439 2017-02-13 18:44:25

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,241
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I find it hard to believe that this could be a WM issue.  I use just about the most braindead WM ever: ~150 lines of C written just for me that I *know* fails to handle most GTK3 windows, has zero EWMH compliance, and only a bare minimum of ICCCM handling.

EDIT: My WM that *does* have these dropdowns working just fine is basically this.  I've made a few modifications since I last pushed it to github - mostly deletions of unneeded features - but I don't think there've been any changes in window handling.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#440 2017-02-13 19:01:09

The Compiler
Member
From: Winterthur, Switzerland
Registered: 2011-05-01
Posts: 213
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Ambrevar wrote:

What's the point of spawning a "normal" window for the dropdown?

As said, it's a bug. The original change (changing the flags from Qt::ToolTip to Qt:Tool) was introduced because of some issues with QWebEngineViews inside modal dialogs on OS X, but apparently that caused it to be handled as a normal window at least on X11.

Trilby wrote:

I find it hard to believe that this could be a WM issue.

I haven't looked at your code, but I'm guessing it's not a tiling WM. I think the menus appear correctly if they get displayed under the cursor - but if they're moved away (like with a tiling WM) they'll disappear.


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

#441 2017-02-13 19:40:37

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,241
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Mine is a fullscreen tiler.  All windows are sized to the screen as soon as they are mapped.  The only exceptions are those that are override_redirect windows which absolutely no WM should ever touch, or those that have the transient-for hint set which no ICCCM-compliant window manager would try to move/place.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#442 2017-02-13 19:42:42

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 29,046
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

The Compiler wrote:
Trilby wrote:

I find it hard to believe that this could be a WM issue.

I haven't looked at your code, but I'm guessing it's not a tiling WM. I think the menus appear correctly if they get displayed under the cursor - but if they're moved away (like with a tiling WM) they'll disappear.

Works fine in dwm.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#443 2017-02-13 20:08:13

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,241
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I just confirmed the dropdown menu window does have the proper transient-for hint set.  If I remove the check of this hint from my WM I did get some odd behavior: when I open the dropdown menu the menu is fullscreened for a split second, but it is then resized to the intended size right away.  This suggests the window is mapped with proper size hints already set, and after mapping is again configured to the proper size.  When my WM ignores the transient-for hint, these initial size hints are ignored and the window is mapped fullscreen until the configure request is processed and it is returned to the intended size.  When my WM checks for the transient-for hint and finds it, it maps the window to it's requested size right away.

This really looks more like a WM issue: 2 issues in fact.  First, ignoring the transient-for hint when mapping a window is bad, and 2, not processing to the follow-up configure request is bad.  My WM does both of these, and it really only does the absolute bare minimum of what is *required* by the ICCCM, e.g., what is written as a must while I happily ignore most of the protocol specifications that are written with a should. (edit: oops, apparently these are both actually shoulds in the protocol - but I've never known a WM to not handle these.)

EDIT: then again, if any of the problems are on Wayland, all bets are off.

EDIT 2: if my WM ignores both the transient-for hint *and* discards all configure requests, then I get non-functional dropdown menus.  And for completeness, I tried checking for transient-for while ignoring all configure requests - and the menus work fine.  This seems it should only affect X11 WMs if they do both of these things wrong (either one handled properly seems sufficient for working drop down menus).


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#444 2017-02-13 21:50:34

ayekat
Member
Registered: 2011-01-17
Posts: 1,392
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Trilby wrote:

This seems it should only affect X11 WMs if they do both of these things wrong (either one handled properly seems sufficient for working drop down menus).

My WM should handle transient-for hints and configure requests correctly.
But it should do a lot of things - like allow floating windows to be resized, restoring windows correctly after a restart, not crash on a restart, not occasionally crash out of the blue, ... well, there's a reason I'm the only one using it¹.

AwesomeWM, on the other hand... hmm

___
¹ But I'm rewriting it!

Last edited by ayekat (2017-02-13 21:51:28)


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

#445 2017-02-13 22:01:55

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,241
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Is this WM accessible anywhere?  I'd be happy to try it out and investigate.  If Wayland has it's way, my knowledge of the X11 protocol will soon be of no use - so I may as well get some mileage out of it while I can.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#446 2017-02-13 22:13:10

stupidus
Member
Registered: 2012-02-27
Posts: 124

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I ran into another issue. (Sorry for asking so many questions, but I am currently in the process of migrating from firefox to qutebrowser).
On some sites, such as the google search results or the duckduckgo search results, j and k do not scroll up and down the page, instead they get intercepted by some javascript BS on those sites and jump between search results. On Firefox with vimfx, hjkl still scroll normally even on those sites. I actually had never encountered that "feature" before, so I was kind of surprised when I encountered it with qutebrowser. A quick test showed that even Firefox has this "feature" when using the arrowkeys (which I had never used before). Is there a way to make hjkl just scroll the page?

Offline

#447 2017-02-13 22:17:10

ayekat
Member
Registered: 2011-01-17
Posts: 1,392
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Trilby wrote:

Is this WM accessible anywhere?  I'd be happy to try it out and investigate.

https://github.com/ayekat/karuiwm/tree/legacy - as I said, it's badly written.

Last edited by ayekat (2017-02-13 22:20:01)


{,META,RE}PKGBUILDSpacman-hacks (includes makemetapkg and remakepkg) │ dotfiles

Offline

#448 2017-02-13 22:19:23

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,241
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

FWIW stupidus, that behavior only happens on webkit.  With backend=webengine duckduckgo works "properly".  Webengine does still have some rough edges that are gradually being worked out, but they're nothing compared to the bugs in webkit that will never be fixed and will likely just get worse in time.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#449 2017-02-13 22:25:40

Hund
Member
From: Sweden
Registered: 2010-03-22
Posts: 478
Website

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

The only thing (I think) that's preventing me from ditching WebKit is the horrendous font rendering with the webengine backend. I don't know how to make it as good as with WebKit. hmm

Offline

#450 2017-02-13 22:39:48

stupidus
Member
Registered: 2012-02-27
Posts: 124

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

I have been on the webengine backend all along, and duckduckgo does not work properly. I think the problem is, that hjkl are treated the same way as the arrow keys, and these are caught by some javascript foo.

EDIT: It is actually the opposite, google search results behave normal with the webkit backend. duckduckgo is still sort of sketchy, but not as bad as with the webengine backend.

Last edited by stupidus (2017-02-13 22:42:45)

Offline

Board footer

Powered by FluxBB