You are not logged in.

#101 2021-02-07 03:17:58

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

Re: Weaver: a socket controlled web browser

I guess only one weaver server can be run at a time. So to enter private mode one will need to close the running server and start new server with empty profile string.

Last edited by Docbroke (2021-02-07 03:33:37)


Arch is home!
cwm rofi weaver vifm vis lizzy pass terminator
https://github.com/Docbroke

Offline

#102 2021-02-07 03:34:34

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

Re: Weaver: a socket controlled web browser

At the moment, yes.  But I realized shortly after the above changes that I could have the socket named after the profile.  So it'd be easy to have multiple instances of the server running.  This would, however, also require that every client call inherited the proper environment variable - and given how poorly understood environment variables generally are, paired with the fact that the weaver client calls may come from a key binding which couldn't inherit changes in environment variables - I think it could be a recipe for disaster.  But I'm still mulling it over.  Input it welcome.


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

Offline

#103 2021-02-07 04:09:15

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

Re: Weaver: a socket controlled web browser

I guess weaver client may have to call server using something like "weaver --profile=dataminers open-window www.google.com" and when --profile is not specified simply user default weaver socket ($USER).

EDIT: I may not have enough spare keybindings to use with all these permutations, therefore I will may have to use terminal while using any non-default profile.

EDIT: Memory usage won't double with two server sockets, is that right ?

Last edited by Docbroke (2021-02-07 04:22:57)


Arch is home!
cwm rofi weaver vifm vis lizzy pass terminator
https://github.com/Docbroke

Offline

#104 2021-02-07 04:44:11

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

Re: Weaver: a socket controlled web browser

Docbroke wrote:

EDIT: Memory usage won't double with two server sockets, is that right ?

Most likely, yes, as the qtwebengineprocess processes will be isolated from one another.  Do you regularly use multiple profiles simultaneously?


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

Offline

#105 2021-02-07 04:53:30

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

Re: Weaver: a socket controlled web browser

Not regularly. I just like to have different profile for google and friends, as I don't want to be logged in automatically with google account while using sites like youtube. To be honest, being able to run two profiles simultaneously is just good to have thing, but not necessity. For me other things in todo list, ( handling downloads, pdf, fullscreen youtube etc.) are more important.

EDIT: and I think having two profiles may actually be cumbersome, as one will need two sets of keybindings, or use terminal.

EDIT2: Can we have few basic inbuilt default keybindings (may be similar to firefox), like F5 for refresh, and Ctr+/- (for zoom), gg or G (top, bottom scroll), C-[, C-] ( history-back,history-forward). Reason being, if i bind F5 to refresh weaver, I cannot use F5 with firefox or libreoffice, but with inbuilt shortcuts same shortcut can be used with multiple applications.

Last edited by Docbroke (2021-02-07 05:20:47)


Arch is home!
cwm rofi weaver vifm vis lizzy pass terminator
https://github.com/Docbroke

Offline

#106 2021-02-07 05:24:04

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

Re: Weaver: a socket controlled web browser

Actually ... there can be multiple profiles with a single server instance and a single (set of) QWebEngineProcess processes.  I just designed the current implementation thinking a user would chose one at startup, but there is another approach that'd work.  So I'll get that on the todo list as well.  In fact, the other approach might even be easier and I could do away with the environment variable all together... now that I'm thinking about it, the per-page approach is much better.


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

Offline

#107 2021-02-07 05:43:43

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

Re: Weaver: a socket controlled web browser

Yes, single sever with multiple profiles sounds much better.
Have you read my Edits in previous post?


Arch is home!
cwm rofi weaver vifm vis lizzy pass terminator
https://github.com/Docbroke

Offline

#108 2021-02-07 06:23:46

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

Re: Weaver: a socket controlled web browser

I hadn't seen your edits: I was busy reimplementing profiles which was just pushed.  Now for anyone (or the one person) who has updated today, you should move your profile back from $USER to "Default".  There will be no need for different sets of key bindings for the different profiles.  Each new window opens with the Default profile, but you can change it with "weaver set-profile MyProfile" where MyProfile can be a string/name which will just create an additional (but not "incognito") profile with it's own set of cookies / cache, etc.  Or if no argument is passed ("weaver set-profile") then the page is reset to the Default profile.  Finally if the special string [mem] is given with the brackets as "weaver set-profile [mem]", then a memory-only profile is used.

The specified profile remains in effect on the single window in which it was specified until that window is closed.

On the key bindings, I wanted to just say "no", but felt bad about it ... until I realized all of that can be accomplished with a userScript!  So now I feel good about saying No to that.  But I can try to put together a userScript that demonstrates how to acheive that.  But binding "gg" or some such wouldn't make sense as weaver is modeless.  In fact I didn't note it in my first post, but that was a primary motivation too.  I like qutebrowser's modes - in principle.  But in practice, there are so many websites with horrific focus models that I was always fighting with it as it would fall in and out of insert mode at the most unusual and unpredictable times.  If you type 'gg' in weaver, those g's are likely landing in a text-field on the website.  But here's a userscript to get you started Alt+{h,j,k,l} for history and scrolling:

// ==UserScript==
// @name keybinds
// @description example of binding keys in javascript
// ==/UserScript==

document.onkeyup = function(e) {
	if (!e.altKey) return;
	switch (e.keyCode) {
		case 72: window.history.back(); break;
		case 74: window.scrollBy(0,80); break;
		case 75: window.scrollBy(0,-80); break;
		case 76: window.history.forward(); break;
	}
};

Last edited by Trilby (2021-02-07 07:01:38)


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

Offline

#109 2021-02-07 07:19:25

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

Re: Weaver: a socket controlled web browser

thanks, that all is wonderful.
Where can I get those keycodes ( I don't think they are the same codes displayed by xev, as case 72/74/75/76 are not hjkl)
Which other functions are available to bind ?
I changed alt to ctrl and it worked, but guessing other keys would be difficult.
EDIT: I think I need to learn a lot about userscripts.
EDIT2: found these are javascript keycodes

Last edited by Docbroke (2021-02-07 08:04:25)


Arch is home!
cwm rofi weaver vifm vis lizzy pass terminator
https://github.com/Docbroke

Offline

#110 2021-02-07 08:22:43

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

Re: Weaver: a socket controlled web browser

You could also use these two HTML/JS files, if you download both and also the query.js and put it in a folder it's one click away and local;)
(see)https://api.jquery.com/event.which/

Offline

#111 2021-02-07 08:40:53

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

Re: Weaver: a socket controlled web browser

Thanks qinohe, this is better as I can now get keycodes locally.
I still need to find out list of functions supported by weaver, so I can bind them using userscript.


Arch is home!
cwm rofi weaver vifm vis lizzy pass terminator
https://github.com/Docbroke

Offline

#112 2021-02-07 08:54:00

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

Re: Weaver: a socket controlled web browser

Trilby gave a pretty good example in #108, don't you recognize the names?
I give you a hint ;-) Weaver frontpage...

Offline

#113 2021-02-07 09:16:29

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

Re: Weaver: a socket controlled web browser

I see resemblence with weaver command names, ( history-back becomes window.history.back and scroll-by becomes scrollBy),
You see that is not consistent as in one command - becomes ., and other - is removed and next b is capitalized.
Thanks for the hint though, I will do trial and error method.


Arch is home!
cwm rofi weaver vifm vis lizzy pass terminator
https://github.com/Docbroke

Offline

#114 2021-02-07 10:37:52

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

Re: Weaver: a socket controlled web browser

Well, that's just how you notate in JavaScript. F.I. 'window' is optional because it's global and variables etc.belong to it.
You can see this example described here (see) https://www.w3schools.com/js/js_output.asp.
It's not that I 'know' JS but that site is a good reference if you need to 'figure it out'.

Offline

#115 2021-02-07 14:29:20

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

Re: Weaver: a socket controlled web browser

UserScripts are javascript.  Any similarity in naming of weaver functions is coincidental ... well, coincidental, and "convergent" as there are only so many sensible ways to label the same behavior.  Any valid javascript will work.

The only difference is that there should be no need bring your own jquery.  Qt provides jquery, there's just a particular way to initize it in the javascript that I have to look up.  I avoid jquery so I just didn't bother noting this initialization.  Especially now that standard javascript* has document.querySelector I see no reason at all to ever use jquery.  But if you want it, I'll find the reference to how to use qt's implementation.

As for the keycodes, they are just JS keycodes.  Allegedly they're just the ascii value - but I'm not sure what that means for things like F5.  But again, it's just javascript, so test: throw an "alert(keyCode);" in there, load a page, then press the key - you'll get a dialog window showing the value of the key.

*edit: document.querySelector is actually the DOM specification, not javascript, but the result is the same.

edit 2: the qt jquery apparently may require a webchannel interface between qt objects and js objects which I've not implemented and don't have any current plan of implementing.  So if you want jquery for now, bring/link-to your own.  But really, jquery does absolutely nothing in the context of userscripts that standard javascript couldn't do with simpler syntax and lower resource use.  I'm critical of it overall, but it has some merits in generating modern-looking dynamic page content, but there'd be no reason to do this in a userscript.

The javascript based search/find is pretty damn handy too:

// ==UserScript==
// @name keybinds
// @description example of binding keys in javascript
// ==/UserScript==

var needle = "";

document.onkeydown = function(e) {
	if (e.altKey) switch (e.keyCode) {
		// h,j,k,l: history / scrolling
		case 72: window.history.back(); break;
		case 74: window.scrollBy(0,120); break;
		case 75: window.scrollBy(0,-120); break;
		case 76: window.history.forward(); break;

		// f,n: find / find-next
		case 70: needle = prompt("Search String"); window.find(needle, false, false, true); break;
		case 78: window.find(needle, false, false, true); break;

	}
	else if (!e.altKey) switch (e.keyCode) {
		// F5: reload
		case 116: location.reload(); break;
	}
};

THIS is the really fun part of writing code in the above-mentioned "lego" style.  Even the one writing it will discover unforseen handy features.

EDIT: and there's the F5 reload.

Last edited by Trilby (2021-02-07 15:49:15)


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

Offline

#116 2021-02-07 23:27:31

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

Re: Weaver: a socket controlled web browser

Well, I wasn't planning on using jquery for weaver it's just that the script converts keypresses to ASCI code.
But your right, there are easier ways, here's one for both ASCI, no jquery needed;)

<!-- Unicode & ASCI key numbers -->

<br><h4>Unicode Key:</h4>
<input type="Unicode" size="20" onkeypress="UnicodeFunction(event)">
<p id="uni"></p>

<br><h4>ASCI Key:</h4>
<input type="ASCI" size="20" onkeydown="ASCIFunction(event)">
<p id="asci"></p>

<script>
function UnicodeFunction(event) {
  var uc = event.which || event.keyCode;
  document.getElementById("uni").innerHTML = "The Unicode value is: " + uc;
}
function ASCIFunction(event) {
  var ac = event.which || event.keyCode;
  document.getElementById("asci").innerHTML = "The ASCI value is: " + ac;
}
</script>

Want to get Unicode numbers change 'onkeydown' to 'onkeypress' and change function names, put them both in a HTML file...


I haven't tested the new Weaver fully, but it looks good I like the little search box, however dmenu can also do similar if you use 'xyz' patch you can even place it at the 'normal' place(fullscreen).
Dmenu is still in use here for starting / quitting a forked socket and for bookmarks and URL input etc..
Weaver it's becoming the browser I like more & more BTW..

edit: added both  'onkeydown' & 'onkeypress'  to the script;)

Last edited by qinohe (2021-02-08 00:05:04)

Offline

#117 2021-02-08 00:25:34

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

Re: Weaver: a socket controlled web browser

qinohe wrote:

however dmenu can also do similar if you use 'xyz' patch you can even place it at the 'normal' place(fullscreen).
Dmenu is still in use here for starting / quitting a forked socket and for bookmarks and URL input etc..

You can call dmenu from javascript?


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

Offline

#118 2021-02-08 00:34:33

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

Re: Weaver: a socket controlled web browser

Ah, of course, I'm using i3 it has 'modes'  so call it 'old habits die hard' :-)
Than far as I can tell I will probably only need it to start / stop the 'jailed socket' from dmenu, nice.

Offline

#119 2021-02-08 00:37:24

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

Re: Weaver: a socket controlled web browser

What are you talking about?  I'm not sure what habits you are talking about, nor why they should die.  I don't beleive dmenu can be called from javascript, so dmenu would not be of use for javascript key bindings.  But most interaction with weaver is still done via the socket which may be through something like dmenu - the javascript key bindings are an optional add-on you can work with so you don't have to use system-wide key bindings calling dmenu: but you still can.

Last edited by Trilby (2021-02-08 01:44:33)


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

Offline

#120 2021-02-08 00:52:19

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

Re: Weaver: a socket controlled web browser

Well, I must say, I was under that impression too, security springs to mind.
But your message made me wonder and think maybe I'm wrong. but I ain't, clear!

Well, I know most things can be interacted with directly from Weaver, but calling and storing bookmarks is nicer with dmenu, at least that's how I think about it at the moment, that may change who knows...;)
There are so many ways, I'll try some now and then..

Offline

#121 2021-02-08 01:43:44

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

Re: Weaver: a socket controlled web browser

Are your recent post being generated by a random text generator?  You were under what impression too?  Security of what springs to mind and why?  I'm sorry I haven't the foggiest clue what on earth you've been talking about for the past several posts.

On (another) topic, Fullscreen ability was just pushed to the project page.


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

Offline

#122 2021-02-08 02:07:14

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

Re: Weaver: a socket controlled web browser

Trilby wrote:

Are your recent post being generated by a random text generator?  You were under what impression too?  Security of what springs to mind and why?  I'm sorry I haven't the foggiest clue what on earth you've been talking about for the past several posts.

I see, I need too quote everything, all I say is about your tool and the use of it;) You can't use javascript to open external programs, that would be a security risk and javascript is pretty tight.
I was under the impression you meant in #117 that you can open a program with javascript and was wrong thinking you couldn't. I was right thinking that it is not possible, a security risk, but hey NVM..
The rest I was saying doesn't really matter it was about different ways I use Weaver with, dmenu, i3 shortcut's(modes) etc.

On (another) topic, Fullscreen ability was just pushed to the project page.

Nice.

Offline

#123 2021-02-08 02:31:22

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

Re: Weaver: a socket controlled web browser

And downloads have just been pushed - tomorrow I'll add a way to set the download location, now it just goes to a qt default which is ~/Downloads/.


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

Offline

#124 2021-02-08 03:56:31

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

Re: Weaver: a socket controlled web browser

Trilby wrote:

And downloads have just been pushed - tomorrow I'll add a way to set the download location, now it just goes to a qt default which is ~/Downloads/.

Super.

When I go back from full-screen youtube, weaver window is unmaximized ( I am using cwm, if that matters ). I use weaver in maximized window --> full screen youtube video --> when I remove fullscreen I get unmaximized weaver window.


EDIT: I am not able to download using weaver. I tried to download this https://drive.google.com/file/d/1FqFHkn … IsMOr/view

--> EDIT3: it is actually downloading in $HOME folder, I was looking into $HOME/Downloads.

Which opened a blank window, and that's it. "weaver downloads" command gave me no output.

EDIT2: How to open local html file with weaver ? It opens like text file using weaver open-window file:///<path>

Last edited by Docbroke (2021-02-08 04:59:09)


Arch is home!
cwm rofi weaver vifm vis lizzy pass terminator
https://github.com/Docbroke

Offline

#125 2021-02-08 16:54:11

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

Re: Weaver: a socket controlled web browser

The mechanics for fullscreening are fairly limited as qt is cross platform.  On linux/x11 I believe it uses EWMH (though it's documentation only refers to it as "post-ICCCM").  There are only two signals I'm aware of: one to request the window manager fullscreens the window, and another to request the window manager returns the window to "normal" which should be whatever it was before.  It should be up to the WM to remember the previous state.  I can try to see if there are ways to work around this - but I'm just not sure this is something that should even be weaver's responsibility.  Note there is an alternative approach: right now the fullscreened media is kept in the same window that it came from, and the window manager is asked to make that window fullscreen, then normal; it's possible for the media to pop up in a brand new window that requests to be fullscreened, and when the user exits fullscreen, that window is destroyed.  This way there'd be no change in the original window state - but I'm not inclined to take this approach.  I think I could put in the code for it as a compile-time option, though.

"weaver downloads" will only list downloads currently in progress.  Items are removed from the list when they are complete.  The blank window seems to be from google drive - it does a lot of redirects with download links.  If you right-click -> "save link as" on any link that points to an actual resource, there is no blank window.  The download links on google drive, however do not point to an actual resource, but I think some javascript which opens a new window which in turn triggers a download.

The different download location is due to how qt5 determines the default download location.  I suspect it accepts configurations from xdg directory settings (which would also be influenced by any DE settings).  I'll likely stick with this, but I'd like to provide a link to the documentation on how to configure this.  EDIT: the download location is picked up (at least) from XDG_DOWNLOAD_DIR if specified in ~/.config/user-dirs.dirs.


I'm unable to replicate the issue with opening local files.  I created an html file in /tmp and opened it with "weaver open-window file:///tmp/test.html"; the content was properly rendered as html.  Can you provide a (minimal) example of a file that fails to be rendered?  EDIT: I get a non-rendered text-only if the file does not have a recognized extension, at least .html and .htm are both recognized and rendered as html.

Last edited by Trilby (2021-02-08 17:18:15)


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

Offline

Board footer

Powered by FluxBB