You are not logged in.

#1 2021-01-29 16:40:37

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Weaver: a socket controlled web browser

Weaver - take control of your web.

Weaver is a webengine-based browser with most of the user control provided by a unix socket.

The original motivation came from the realization that almost everything I do on my computer was either in a terminal running tmux, or a browser with a few tabs open.  I really only had two windows, but each of them had a set of tabs (I'd open a image viewer or a pdf reader as needed, but these were more short-lived).  Tmux and my browser each had their own key bindings for managing tabs (opening, closing, focusing, etc).  So I had each of these sets of key bindings, plus another from my WM to cycle between the tmux and browser windows.

I wanted to stream line this into a single interface but also wanted to integrate the "tabs".  When viewing my tmux window I could only see the tmux tabs across the top.  When viewing the browser window, I could only see the browser tabs.  A window manager can readily provide a similar tab bar with window names, but then there'd be two nested tab-bars: one with only two tabs, and each of those with several.  I wanted one display of window titles / tabs and each terminal and browser window to be treated similarly.

Weaver does *not* do this.  As the above is the job of a window manager.  But I need my browser to play well with this.  Some highly configurable browser (e.g., qutebrowser) could be pressed into working reasonably well in such circumstances, but I 1) ran into a few hurdles and 2) realized I was disabling a vast majority of that browsers now-unneed features.

So I wrote my own webengine browser.  Weaver is defined as much by what it doesn't (and will never) do as by what it does. Weaver is not a window manager, you should already have one of those. Weaver is not an adblocker, you have one already at /etc/hosts. Weaver is not a shortcut manager, you can make one with a couple lines of shell script (or use the provided example). Weaver IS designed to play well with others.

Weaver does not have any gui for typing in a url.  It receives such input only via a unix socket.  There is no need for a browser to provide it's own mechanism of user input - if you are in the target audience of weaver, you already have a text-input tool you like - this may be dmenu, rofi, or any number of others.  Examples are provided showing how to use dmenu with weaver - e.g., a key binding can launch dmenu so you can type in a url or search term and a weaver page will open for that input.

I've found my own additional use for weaver that I didn't even anticipate: I have an old (mostly broken) laptop connected to my TV for whatching amazon/netflix shows.  I have a presentation remote that I can control most things with for this poor-mans-media-center, but I fairly regularly have to reach around the tv to the broken-laptop keyboard for some operations.  As weaver commands all come through a unix socket, I can shell in to the media-center and give precisely the commands I want from the other end of the room.

More information can be seen on the project page.  Note the TODO list; weaver is very much a work in progress.  There are features (in the TODO list) that will be added that are completely non-existent.  But there are non-features also described in that page and above that will never be added.  Suggestions for new commands to do useful tasks are most welcome - suggestions for making a gui user interface beyond the web page display will most likely be rejected.

I've just added userscripts, which are so far completely undocumented.  Scripts are read from ~/.config/weaver/scripts/*.js and are a "greasemonkey-light" format provided by webengine / QWebEngineScript. Here's one I use to add custom css to these forums (I use the cobalt theme on the forums, and these modifcations make it much more pleasant for me):

// ==UserScript==
// @include https://bbs.archlinux.org/*
// ==/UserScript==

css = document.createElement('style')
document.head.appendChild(css);
css.innerText = `
.pun {
	max-width: 95rem !important;
	font-size: 1rem !important;
}
`;

The PKGBUILD will be coming to the AUR soon and the link will be placed here when it's ready.  The linked PKGBUILD works / should work well - but given the number of bonehead mistakes I've been making tonight, I want to look it over fresh in the morning before uploading it to the AUR.

Last edited by Trilby (2021-01-31 03:50:18)


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

Offline

#2 2021-01-29 19:47:55

CarbonChauvinist
Member
Registered: 2012-06-16
Posts: 323

Re: Weaver: a socket controlled web browser

The original motivation came from the realization that almost everything I do on my computer was either in a terminal running tmux, or a browser with a few tabs open.

This pretty much describes my workflow as well, though I use a DE.

So I wrote my own webengine browser.

Impressive. Are there any limitations to this as far as what pages can be browsed/media consumed? Reason I ask is (coupled with your TODO note of maybe incorporating a webkit backend) I'm unsure what limitations this browser would have? Is it meant to be able to for instance allow for youtube/netflix or other drm enabled sites? Does this question even make sense?

Edit -- I guess what I'm really asking is where exactly does "webengine based browser" mean? My quick google-fu was less than helpful. It seems like webengine is a Qt project? And may be the basis of qtbrowser? Do any other browsers use this engine?

Examples are provided showing how to use dmenu with weaver

I browsed around the link you provided and couldn't find these, is there a link I'm missing?

A PKGBUILD will be coming to the AUR soon and the link will be placed here when it's ready.

Can't wait.

As a small OT question, where did you run into Fossil? Is this something you've used before for other projects? What made it attractive for your use case?

Last edited by CarbonChauvinist (2021-01-29 19:55:01)


"the wind-blown way, wanna win? don't play"

Offline

#3 2021-01-29 19:53:35

ugjka
Member
From: Latvia
Registered: 2014-04-01
Posts: 1,556
Website

Re: Weaver: a socket controlled web browser

Could be problematic with google as it randomly blocks chrome wrappers

Info https://www.zdnet.com/article/google-ba … -phishing/


Fix yo shit: journalctl -b -p warning
Github

Offline

#4 2021-01-29 20:06:49

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

CarbonChauvinist wrote:

Impressive. Are there any limitations to this as far as what pages can be browsed/media consumed?

Not really.  This uses QWebEngine as the rendering engine which is about the same as chromium, and identical to qutebrowser, falkon, konqueror, and some other major browsers.  There are current limitations in handling things like fullscreening of videos - but this is temporary as that simply hasn't been implemented yet.

Youtube works just fine on weaver.  Netflix, Amazon prime, and related services can also work but require installation of the widevine plugin (just as do the other browsers mentioned above).  I may have to do a bit of tweaking to ensure the plugin is picked up from the right path - IIRC, Florian had to account for this in qutebrowser to be able to use the same widevine as chromium rather than needing it packaged in a different lib path.

The webkit backed on the TODO list exists because I actually started this with webkit.  I wanted to use webengine all along, but webengine kinda sucks as a library - especially for a C programmer (maybe seasoned C++ programmers would feel more at home with it).  Webkit is much more accessible for a C programmer.  So I got the webkit pilot project off the ground very quickly.  But then I started using it - and while webkit is great from a programmers perspective, it really sucks as a rendering engine.  I started realizing how much I'd have to work around for it to function with real-world websites.  So I tried webengine again, and the process I was able to make with webkit got my foot in the door, so to speak, and the second try at webengine was a bit easier (still many struggles for a C programmer, but I had the momentum needed to overcome them).

At this point, while I'm annoyed about some of the API quirks, webengine is just so far superior of a rendering engine, I'm not sure how much motivation I'll find to bring webkit up to speed.  So that's on the back burner for a while.  I do not ever intend to work around webkit's quirks - so the webkit version will always fail on some websites and I'll leave it to the webkit devs to work around that.

As a tangent, one of the API quirks of QWebEngine is the absolute rejection of any syncronous activity.  One feature I planned on adding was being able to send a JS command to the current page and get the results.  An example use case would be to easily extract all urls on the page.  While this is pretty easy to do, there is no way to run the JS syncronously which would be required to send a command on the socket and get the result as a reply.  There are ways to run the JS asyncronously, and have a callback store the result somewhere so the client can make two calls via the socket (e.g., 1. Run something, 2. Check results), but this is an ugly hack that I've pretty much ruled out.  Webkit can readily make syncronous JS calls ... oh well.

ugjka wrote:

Could be problematic with google as it randomly blocks chrome wrappers

Info https://www.zdnet.com/article/google-ba … -phishing/

That's not relevant here - and I was surprised by the date on that article.  I thought CEF was dead years ago.  As noted above, weaver links to the QT implementation of webengine, QWebEngine.  It does not use CEF or any embedded chrom(e|ium).

CarbonChauvinist wrote:

I browsed around the link you provided and couldn't find these, is there a link I'm missing?

If you look at the "File" in the repo, there is an examples directory.  Admitedly the reference to "examples" was written a bit prophetically as more will be coming, but the "shortcut" script as well as the "xbindkeysrc" both show the integration with dmenu.

CarbonChauvinist wrote:

where did you run into Fossil? Is this something you've used before for other projects? What made it attractive for your use case?

It's been my prefered SCM for quite some time.  I used git in order to get exposure on github, but now I'm content to not fly as big of a banner for my projects.  I think the fossil page itself lays out its pros and cons better than I could.  There have been some threads on it on these forums too over the years.  Feel free to search or create a new one of those and I'd chime in, but I'd not want to go down that rabbit hole on this thread.

Last edited by Trilby (2021-01-29 20:21:33)


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

Offline

#5 2021-01-29 20:12:22

ugjka
Member
From: Latvia
Registered: 2014-04-01
Posts: 1,556
Website

Re: Weaver: a socket controlled web browser

Well, Falkon uses QWebEngine too and I had to stop using it because google locked me out

Edit: my post on Reddit https://www.reddit.com/r/kde/comments/e … _browsers/

Last edited by ugjka (2021-01-29 20:13:28)


Fix yo shit: journalctl -b -p warning
Github

Offline

#6 2021-01-29 20:18:10

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

I've been using qutebrowser (QWebEngine) for years and have not had issues with any google services.  I guess there are other factors involved.  But yes, anything that Falkon and Konqueror would fail on, weaver would too.

EDIT: FYI, according to that redit thread, it seems using a different UA string solved other users' problems.

Last edited by Trilby (2021-01-29 20:20:13)


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

Offline

#7 2021-01-29 20:25:32

ugjka
Member
From: Latvia
Registered: 2014-04-01
Posts: 1,556
Website

Re: Weaver: a socket controlled web browser

That's the fun thing, what stops the bad guys from changing the UA if this is google's super duper security check

Okay, that's offroading offtopic

Last edited by ugjka (2021-01-29 20:25:51)


Fix yo shit: journalctl -b -p warning
Github

Offline

#8 2021-01-29 20:30:11

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

I just saw this edit:

CarbonChauvinist wrote:

Edit -- I guess what I'm really asking is where exactly does "webengine based browser" mean? My quick google-fu was less than helpful. It seems like webengine is a Qt project? And may be the basis of qtbrowser? Do any other browsers use this engine?

Webengine is googles rendering engine - also known as Blink.  I believe they've gone back and forth a few times on which is the official name.  But this is the same rendering engine used by chrome/chromium, webengine is a google project, not a Qt project.  The actual library I'm using is the Qt5 implementation of webengine, or QWebEngine.  This implementation is used by the browsers listed in previous posts including qutebrowser, konqueror, and falkon off the top of my head.

---

I don't know who "bad guys" are referring to.  But in no case is a UA string a "security" measure.  The rendering engine renders google service pages just fine.  If google service pages reject certain user agent strings, that has nothing to do with the rendering engine, or this project.

And FYI, I just tested and I'm rejected from google calendar on Falkon, but I use google calendar all the time on qutebrowser.  So the issues with google websites have nothing to do with the rendering engine.

Also I did just sign in to google calendar with weaver.  Though I did have to change the UA.  Apparently there is no actual securty check, google just blocks any browser with QtWebEngine in the UA string and lies about the reason.

Last edited by Trilby (2021-01-29 21:01:56)


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

Offline

#9 2021-01-29 23:58:21

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,265

Re: Weaver: a socket controlled web browser

@Trilby, seems to work very well here(so far) created a PKGBUILD and installed it.
I'm writting this post from it right now;) It's very small too, executable seems to be only 70KB.
I'll await it's updates, thanks.

Offline

#10 2021-01-30 00:42:19

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

Thanks - being absolutely tiny is a primary goal too.  Hence it being defined by a number anti-features that will never be part of weaver.

I also forgot to mention in the initial post as I perhaps just take it for granted, but weaver is most suited to tiling (or fullscreen) WMs.  I suspect it would (or soon will) be great under i3, as i3 provides the tab management.  It shoud also be right at home in dwm, and definitely in ratpoison.  I was thinking it might be fun to fire up fluxbox again: despite being a floating wm, fluxbox has tab containers which should provide ample opportunities for interesting configurations with weaver.

The above also hopefully highlights my thinking about weaver: it provides a few legos that creative users should be able to put together with their other lego-like tools to create their own setup; on the flip side, weaver doesn't provide much of a nicely polished final product (as doing so would hinder integration with other tools).  I suspect this means it may not be ideal for floating / stacking WMs (with a possible exception of fluxbox).

It's a bit OT (but hey it's my thread) but I've been thinking for some time about my own software philosophy.  While I appreciate the "unix philosophy" of "do one thing and do it well", there are fair criticisms of that mantra - especially in modern GUI systems.  Weaver doesn't do just one thing - but I do limit it's scope quite deliberately.  So in place of "do one thing and do it well" I'm embracing "Make and distribute legos": make tools that define what they do and dont do, and focus on facilitating their integration with other tools.


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

Offline

#11 2021-01-30 01:23:10

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,265

Re: Weaver: a socket controlled web browser

Trilby wrote:

I also forgot to mention in the initial post as I perhaps just take it for granted, but weaver is most suited to tiling (or fullscreen) WMs.  I suspect it would (or soon will) be great under i3, as i3 provides the tab management.  It shoud also be right at home in dwm, and definitely in ratpoison.  I was thinking it might be fun to fire up fluxbox again: despite being a floating wm, fluxbox has tab containers which should provide ample opportunities for interesting configurations with weaver.

I'm using it together with i3, tried it tabbed as well as tilling and full screen, all work well.
Guess, by tabbed you mean the WM not tabbed support for weaver...?

The above also hopefully highlights my thinking about weaver: it provides a few legos that creative users should be able to put together with their other lego-like tools to create their own setup; on the flip side, weaver doesn't provide much of a nicely polished final product (as doing so would hinder integration with other tools).  I suspect this means it may not be ideal for floating / stacking WMs (with a possible exception of fluxbox).

I have just build and installed it I'm going to try and use it's 'lego' options later on if I have a little more time for it;)

It's a bit OT (but hey it's my thread) but I've been thinking for some time about my own software philosophy.  While I appreciate the "unix philosophy" of "do one thing and do it well", there are fair criticisms of that mantra - especially in modern GUI systems.  Weaver doesn't do just one thing - but I do limit it's scope quite deliberately.  So in place of "do one thing and do it well" I'm embracing "Make and distribute legos": make tools that define what they do and dont do, and focus on facilitating their integration with other tools.

Well, it's your party, I just invited myself;-) and hope to enjoy it, get some ideas etc..
I already added the info,html to install part of the makefile, it gets installed in '/usr/share/doc' a man page may be better, I make that later.
Already I found I see no way to zoom the page so characters are small but I'll figure it out I think..

Offline

#12 2021-01-30 02:07:45

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

qinohe wrote:

Guess, by tabbed you mean the WM not tabbed support for weaver...?

Correct.  With weaver every page is it's own window - but it's assumed that a WM would organize these windows in a useful way effectively as "tabs" in the WM which i3 does explicitly.

qinohe wrote:

Already I found I see no way to zoom the page so characters are small but I'll figure it out I think..

There are three options, 1) I did not include a key for it in the provided xbindkeysrc - but there are the commands zoom/Zoom.  These zoom all content, however, not just text.  2) There is a setting for a default font size which I've not (yet) exposed to the user.  I likely will never make this a run-time customization, but will likely add comments to the WebView::init() and some documentation guiding users to make any compile-time adjustments there. and 3) Userscripts can add custom css - this might be the best approach if you just generally want all fonts to appear larger.  See the archlinux.js example in my original post and just remove the @include line (or make it a wildcard match to any/all urls) and change the .pun specifier to either html or body.  E.g.:

// Set some default fonts

css = document.createElement('style')
document.head.appendChild(css);
css.innerText = `
html { font-size: 18pt; }
`;

EDIT: actually there is a 4th option too.  While many browsers do allow for the #2 option above, I've never been fond of the approach.  The web browser should not set font preferences as that's stepping on fontconfig's toes.  If you want "PT Sans" to be the default sans-serif font on web pages, that's great, so do I.  But I don't need my browser to enforce this, my fontconfig settings can do that.  So why make yet another place to forget to configure something which only makes it harder for users to enforce their preferences system-wide?  The more I think about this, the worse option #2 seems - I may not even put that compile-time configuration in there: use fontconfig!

EDIT: oh, and as for the info.html, sorry that's no longer in the source repo!  I've moved that information into the Fossil wiki.  There WILL be a man page forthcoming.  I've never been fond of writing documentation, but I've learned that the only way to maintain any motivation to write it is to not write too much of it too soon while the code is still in flux.  I need to work with the code a bit more to settle a few up-in-the-air issues that will dictate how some of the documentation should work.  I'm not too sure on a timeline - but I'd say a week or so and I should be able to start genuine work on documentation.  The current state of the code is still well short of being ready for an actual tagged release.

Last edited by Trilby (2021-01-30 02:25:57)


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

Offline

#13 2021-01-30 02:55:32

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,265

Re: Weaver: a socket controlled web browser

Trilby wrote:
qinohe wrote:

Guess, by tabbed you mean the WM not tabbed support for weaver...?

Correct.  With weaver every page is it's own window - but it's assumed that a WM would organize these windows in a useful way effectively as "tabs" in the WM which i3 does explicitly.

Yes, I understood that correctly and that's working perfectly fine in a tilling WM like i3, it does here.

There are three options, 1) I did not include a key for it in the provided xbindkeysrc - but there are the commands zoom/Zoom.  These zoom all content, however, not just text.  2) There is a setting for a default font size which I've not (yet) exposed to the user.  I likely will never make this a run-time customization, but will likely add comments to the WebView::init() and some documentation guiding users to make any compile-time adjustments there. and 3) Userscripts can add custom css - this might be the best approach if you just generally want all fonts to appear larger.  See the archlinux.js example in my original post and just remove the @include line (or make it a wildcard match to any/all urls) and change the .pun specifier to either html or body.  E.g.:

// Set some default fonts

css = document.createElement('style')
document.head.appendChild(css);
css.innerText = `
html { font-size: 18pt; }
`;

EDIT: actually there is a 4th option too.  While many browsers do allow for the #2 option above, I've never been fond of the approach.  The web browser should not set font preferences as that's stepping on fontconfig's toes.  If you want "PT Sans" to be the default sans-serif font on web pages, that's great, so do I.  But I don't need my browser to enforce this, my fontconfig settings can do that.  So why make yet another place to forget to configure something which only makes it harder for users to enforce their preferences system-wide?  The more I think about this, the worse option #2 seems - I may not even put that compile-time configuration in there: use fontconfig!

Well thank you very much for this nice write up, you didn't need to, I would have RTFM anyway;-) I will create a dmenu script and other nice add-ons for my use case and that xbindkeys... I simply forgot to add it to the makefile.. I will look into the fonts also. I'm very much for setting preferences colors, fonts etc. system-wide - it gives an overall quiet equal looking and feeling system, which I like.
It's just it's (late) and I'm under my down feather on the couch while watching a movie, I go further sometime tomorrow ;-)

EDIT: oh, and as for the info.html, sorry that's no longer in the source repo!  I've moved that information into the Fossil wiki.  There WILL be a man page forthcoming.  I've never been fond of writing documentation, but I've learned that the only way to maintain any motivation to write it is to not write too much of it too soon while the code is still in flux.  I need to work with the code a bit more to settle a few up-in-the-air issues that will dictate how some of the documentation should work.  I'm not too sure on a timeline - but I'd say a week or so and I should be able to start genuine work on documentation.  The current state of the code is still well short of being ready for an actual tagged release.

Ah, okay that's where I downloaded the files also so that's nice, had a quick glace already looks nice. No worries BTW. I can understand you're not done with the docuus man etc. and I think most people using your browser need very little info to make everything work they wish it should or even hack the code and get what they want. It's a very nice project for a community like this and especially for the tweaking Archer wink

Offline

#14 2021-01-30 18:13:55

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

Re: Weaver: a socket controlled web browser

Silly question, but how do I obtain the source? I see there is https://code.jessemcclure.org/weaver/dir?ci=tip, and based on the presence of `trunk` and `check-ins`, I now naively assume that it's probably SVN, but… is there any instructions for people like me who are mostly just familiar with Git? big_smile

I fully expect that it might also just be that the instructions are there and I just couldn't find it…


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

Offline

#15 2021-01-30 18:53:24

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,265

Re: Weaver: a socket controlled web browser

@ayekat, it's fossil, install fossil and use 'fossil clone' ;-)

edit: oh, and don't use '/dir?ci=tip' just 'https://code.jessemcclure.org/weaver' same as git BTW..

Last edited by qinohe (2021-01-30 19:07:22)

Offline

#16 2021-01-30 19:18:33

progandy
Member
Registered: 2012-05-17
Posts: 4,271

Re: Weaver: a socket controlled web browser

You can also find a link to a tarball if you click on "latest check-in".

By the way, that project reminds me of uzbl, specifically uzbl-core.

Last edited by progandy (2021-01-30 19:19:00)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#17 2021-01-30 19:41:19

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

Re: Weaver: a socket controlled web browser

Ah yes, `fossil clone` worked smile

Also, indeed, clicking on a check-in actually gives me all the options for downloading the source as a tarball… should've checked that.

Thanks, qinohe and progandy!

--edit This is great! I like the idea of having a socket and just doing everything you need via that. And the concept of targetting the currently focused browser window also makes it simple enough.

Not sure if I'm going to adopt this as my daily browser, but it just invites you to start tinkering around with it, so the addiction level is certainly there big_smile

Last edited by ayekat (2021-01-30 19:47:23)


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

Offline

#18 2021-01-30 21:27:21

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,265

Re: Weaver: a socket controlled web browser

It must be me, but the only way I am able to build a package is to change a few lines in the Makefile.
Brought back the '$(PROG)' & 'LICENSE' on line one & two.
Also changed LICENCE, why does it need to have executable rights ... ?
Here's the result:

        install -Dm755 $(PROG) $(DESTDIR)$(PREFIX)/bin/$(PROG)
        install -Dm644 LICENSE $(DESTDIR)$(PREFIX)/share/licenses/$(PROG)/LICENSE
        install -dm644 examples $(DESTDIR)$(PREFIX)/share/doc/$(PROG)/examples
        install -Dm755 examples/* $(DESTDIR)$(PREFIX)/share/doc/$(PROG)/examples

Offline

#19 2021-01-30 23:35:33

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

Thanks qinohoe, I've not been testing the install directive well yet.  I think I dropped the terminal parts of target path based on the man page for `install` sounding like it wasn't necessary.  I know there's no need for a separate command to make the directory, and a directory should have execute permissions - but actually not all the content needs to.  As for the license being a executable, yeah, that was just me being dumb / lazy copy-pasta.  I'll get the makefile fixes pushed within the next day after I actually test that - and I'll add the PKGBUILD (for a (pre)alpha) version so it's easier to start testing / tinkering.  If you have a  PKGBUILD already, feel free to post that and/or submit it on the project page.

Thanks to those above for adding information on where / how to download.  One generally makes additional download links more visable and accessible, and I plan to as well once this gets a little more TLC on the code.  Right now it's probably best that people who don't RTFM on the SCM don't bother trying to build and use the code just yet tongue

This is currently just past the pilot-project stage to where I knew I was going to keep going and make this into something I'll use regularly - but it's not even fully dog-fooded yet as I'm typing this post from qutebrowser!  (I need to adapt other parts of my WM and general workflow to integrate weaver well, and there's a trade off in working on the weaver code, or working on integrating it into my system).  The current code is the product of just over two days of coding (admittedly after a several months of false starts that never went anywhere and were given up on).

RE: Uzbl, I agree - there's a lot of similarity in scope and goals.  The big differences would be the use of a socket for commands rather than binding keys only when the webpage is focused, and the use of qt/webengine rather than gtk/webkit.  And while I hope to have a webkit version down the road, I'll definitely never write gtk code (OT: I'm not a fan of any toolkits, but I appreciate QTs modularity: it is easy to use a few QT libs/tools without pulling in the rest of the toolkit).

Last edited by Trilby (2021-01-30 23:45:34)


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

Offline

#20 2021-01-31 00:18:16

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,265

Re: Weaver: a socket controlled web browser

Trilby wrote:

Thanks qinohoe, I've not been testing the install directive well yet.  I think I dropped the terminal parts of target path based on the man page for `install` sounding like it wasn't necessary.  I know there's no need for a separate command to make the directory, and a directory should have execute permissions - but actually not all the content needs to.  As for the license being a executable, yeah, that was just me being dumb / lazy copy-pasta.  I'll get the makefile fixes pushed within the next day after I actually test that - and I'll add the PKGBUILD (for a (pre)alpha) version so it's easier to start testing / tinkering.  If you have a  PKGBUILD already, feel free to post that and/or submit it on the project page.

Well,  whatever I try the package will only compile if I use both install 'dm' & 'Dm' and yes I accidentally switched permissions, should be:

        install -dm755 examples $(DESTDIR)$(PREFIX)/share/doc/$(PROG)/examples
        install -Dm644 examples/* $(DESTDIR)$(PREFIX)/share/doc/$(PROG)/examples

without both no go...

I'm repackaging the files myself to a '.tar.gz' with:

tar -czvf weaver.tar.gz weaver

The PKGBUILD could be part of the problem too, both 'LDFLAGS' exports seem to work...,this is what I use:

# Maintainer: none
pkgname=weaver
pkgver=0.1
pkgrel=1
pkgdesc="Socket controlled web browser"
url="https://code.jessemcclure.org/weaver/homel"
arch=('x86_64')
license=('GPL3')
depends=('qt5-webengine' 'qt5-webkit')
makedepends=('gcc' 'make' 'tar')
source=("weaver.tar.gz")
sha256sums=('SKIP')

prepare() {
        tar zxvf weaver.tar.gz
}

build() {
        cd "${pkgname}"
        export LDFLAGS="-Wl,--copy-dt-needed-entries"
#       export LDFLAGS="-lstdc++"
        make
}

package() {
        cd "${pkgname}"
        make PREFIX=/usr DESTDIR="${pkgdir}" install
}

I;m not sure about the license(GPL3)?

Offline

#21 2021-01-31 00:24:28

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

You were getting build errors without additional LDFLAGS?  That should not be.  I've not tested the install directive of the Makefile much, but it should definitely be building without workarounds.  Can you provide error output from the build?


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

Offline

#22 2021-01-31 00:33:39

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,265

Re: Weaver: a socket controlled web browser

Yep, without the LDFLAGS build fails, only the last part, If you want the complete compile messages than I will repast it.
The part which matters:

cc -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -lstdc++  weaver.o client.o server.o webengine.o  -lQt5WebEngine -lQt5WebEngineWidgets -lQt5WebEngineCore -lQt5Positioning -lQt5WebChannel -lQt5Quick -lQt5QmlModels -lQt5Qml -lQt5Network -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Core  -o weaver
/usr/bin/ld: weaver.o: undefined reference to symbol '_ZdlPvm@@CXXABI_1.3.9'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib/libstdc++.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [<builtin>: weaver] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

Offline

#23 2021-01-31 00:41:33

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

Here's a yet untested PKGBUILD, but this should be more what it will look like:

# maintainer: Jesse McClure AKA Trilby <code [at] jessemcclure.org>
pkgname=weaver-nightly
_date=$(date +%Y%m%d)
pkgver=r${_date}
pkgrel=1
pkgdesc='Socket controlled web browser'
url='https://code.jessemcclure.org/weaver'
arch=('x86_64')
license=('MIT')
depends=('qt5-webengine')
source=("${url}/tarball/${_date}/${pkgname}-${pkgver}.tar.gz")
sha256sums=('SKIP')

build() {
	cd "${pkgname}-${pkgver}"
	make
}

package() {
	cd "${pkgname}-${pkgver}"
	make DESTDIR="${pkgdir}" install
}

Let me look into that linker error - that looks like the result of not including -lstdc++ not being picked up by the linker, but that flag is included in the makefile.  You haven't made other makefile patches have you?

EDIT: ah, the flags inherited from makepkg.conf (specifically -as-needed) are not interacting well with this ... give me a bit to figure out what I've got wrong.  The symbol in question is provided by the Qt5-Core library which is properly linked without "-as-needed" but for some reason the linker is determining that that library is not needed ... when it clearly is.

Last edited by Trilby (2021-01-31 02:02:10)


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

Offline

#24 2021-01-31 00:45:30

qinohe
Member
From: Netherlands
Registered: 2012-06-20
Posts: 1,265

Re: Weaver: a socket controlled web browser

No, I didn't make any other edit's to the makefile, only to the 'install' part I showed in #18
Will try that PKGBUILD;)

And this is the error I get when compiling with the examples file:

install -Dm644 LICENSE /home/mark/build/weaver-clone/pkg/weaver/usr/share/licenses/weaver/LICENSE
install -Dm644 examples /home/mark/build/weaver-clone/pkg/weaver/usr/share/doc/weaver/examples
install: omitting directory 'examples'
make: *** [Makefile:23: install] Error 1
==> ERROR: A failure occurred in package().
    Aborting...

edit:with my edit's I get an installable working package...
edit2: I saw your edit I wait a while cool

Last edited by qinohe (2021-01-31 00:49:15)

Offline

#25 2021-01-31 01:10:38

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 25,227

Re: Weaver: a socket controlled web browser

According to this I should just need to include Qt5Core in the DEPS (which is picked up by the pkgconf) but I've added Qt5Core and a laundry list of other qt5 libs to DEPS, and I get the same result.

Can anyone more knowledgeable in building C++ code spot what's wrong?


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

Offline

Board footer

Powered by FluxBB