luakit browser framework (almost with jQuery!)

milomouse · 2011-03-08 17:55:38

mason.larobina wrote:

So is that a webkit issue or are we just missing an #include? I'm going to upgrade and check.

All I know is that after libwebkit 1.3.9 #include soup is missing and luakit wont compile correctly against it (classes/soup/soup.c), which I guess means luakit doesn't include it either(?). Regardless, including it somewhere (in my case; libwebkit) fixes the problem, but perhaps if libwebkit is removing inclusion from newer versions [>=1.3.10] (possibly leaving it up to the developers) then it may be needed in luakit. This is just speculation, though.

mason.larobina wrote:

Added a `globals.load_etc_hosts` option to enable/disable loading of hostnames from /etc/hosts (for those of you with huge /etc/hosts files). Commit: 29875cc

Fantastic. This seems to help as far as initial speed when opening links. There's still a small delay but nothing like before, but I guess that's from checking what the link actually is before proceeding, or something.

mason.larobina wrote:

Ok, there is now an option `follow.sort_labels` which when true sorts the follow labels (default's to true to avoid confusion). Commit: 6c4f224

Thanks, guys. This seems to help some, although I can't say I have the same abstractional mind as javascripters. I find myself delaying still to match a pattern in links, even though I already know what it is. Say if I'm going to follow 661 and there's no 66[2-$] I end up typing the hint too fast and have a left-over 1 in my command buffer. This is tolerable but, when helping the user type less, it causes me (one of these users) to delay more so I don't type too much and/or type each one slower than I normally would. Again, it may just be me.

mason.larobina wrote:

Good point, we should check for search engines first.
-- snip -- Done.

Ok, is there anywhere else this commit is affecting because I patched that block of lines and it still tries to open file://luakit. I removed my window.lua from user folder and let updated /etc/xdg/luakit/window.lua initiate and it still tries for file://. Just wondering what I'm doing wrong.
EDIT^: Ok, I see now, I think. I didn't have a luakit search_engine in my globals.lua so it tried opening it as a file instead. I think it works as intended, sorry for the confusion.. I believe I grasp it now.

Update: Sometimes when working edit fields (like this reply block), I'll right click to copy, paste, or select-all and it will freeze my window-manager. Open terminals still show life (such as mplayer statusline still moving as file plays) but I can't select anything or change focus or quit. I tried in different window-managers, too, also downgrading my current one to almost a year ago -- same results, so I'm guessing it's luakit-develop since it never happened on non-dev luakit. Thankfully I push all output to a log file, so maybe this can help.. not sure how much though. It will repeat this line about 30 times in the log file:

(luakit:5747): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

I typed that out manually because right clicking and pasting it would have froze my screen again (I tried posting this 2 times before).

Last edited by milomouse (2011-03-08 18:44:02)

Army · 2011-03-08 18:49:01

milomouse wrote:

Thanks, guys. This seems to help some, although I can't say I have the same abstractional mind as javascripters. I find myself delaying still to match a pattern in links, even though I already know what it is. Say if I'm going to follow 661 and there's no 66[2-$] I end up typing the hint too fast and have a left-over 1 in my command buffer. This is tolerable but, when helping the user type less, it causes me (one of these users) to delay more so I don't type too much and/or type each one slower than I normally would. Again, it may just be me.

No you're not alone, same here

Army · 2011-03-08 19:12:15

mason.larobina wrote:

milomouse wrote:
Although, I haven't used the development version in a while, has the per site "accept-policy" for cookies changed? I only see a single soup.set_property("accept-policy", cookie_policy.OPTION) and I get warnings when trying to set it per-site.
The trap here is that the "accept-policy" property wasn't a webview setting, it is set globally on the soup cookie jar affecting the accept policy for all tabs and windows (from the same instance). This setting and other global soup properties have been moved to the top of classes/soup/soup.c and it's more appropriate to set them via `soup.set_property(name, value)` in Lua.

Excuse my ignorance, but I don't really understand it.

I understand that the soup.set_property("accept-policy", cookie_policy.never) (that's how I have it right now) is the global setting. By default I want to forbid cookies to be saved, but allow it for specific sites. I know that if I put this line into the per-site settings (domain_props), it still changes the setting globally. So far so good.
But what exactly do I have to put into the globals.lua to get e.g. bbs.archlinux.org to be allowed to store cookies?

karottenreibe · 2011-03-08 19:57:54

milomouse wrote:

mason.larobina wrote:
Ok, there is now an option `follow.sort_labels` which when true sorts the follow labels (default's to true to avoid confusion). Commit: 6c4f224
Thanks, guys. This seems to help some, although I can't say I have the same abstractional mind as javascripters. I find myself delaying still to match a pattern in links, even though I already know what it is. Say if I'm going to follow 661 and there's no 66[2-$] I end up typing the hint too fast and have a left-over 1 in my command buffer. This is tolerable but, when helping the user type less, it causes me (one of these users) to delay more so I don't type too much and/or type each one slower than I normally would. Again, it may just be me.

Yeah, JS tends to stretch ones imagination^^

I added a simple fix here: c4357d1b4c7c
It ignores the keystrokes after a successful follow for 500ms (configure this value with follow.ignore_delay)

Would that solve your problem?

mason.larobina · 2011-03-08 22:56:23

Army wrote:

mason.larobina wrote:
milomouse wrote:
Although, I haven't used the development version in a while, has the per site "accept-policy" for cookies changed? I only see a single soup.set_property("accept-policy", cookie_policy.OPTION) and I get warnings when trying to set it per-site.
The trap here is that the "accept-policy" property wasn't a webview setting, it is set globally on the soup cookie jar affecting the accept policy for all tabs and windows (from the same instance). This setting and other global soup properties have been moved to the top of classes/soup/soup.c and it's more appropriate to set them via `soup.set_property(name, value)` in Lua.
Excuse my ignorance, but I don't really understand it.
I understand that the soup.set_property("accept-policy", cookie_policy.never) (that's how I have it right now) is the global setting. By default I want to forbid cookies to be saved, but allow it for specific sites. I know that if I put this line into the per-site settings (domain_props), it still changes the setting globally. So far so good.
But what exactly do I have to put into the globals.lua to get e.g. bbs.archlinux.org to be allowed to store cookies?

What you're really after is cookie domain whitelisting & blacklisting. I'll work on that today.

mason.larobina · 2011-03-08 23:54:51

milomouse wrote:

mason.larobina wrote:
So is that a webkit issue or are we just missing an #include? I'm going to upgrade and check.
All I know is that after libwebkit 1.3.9 #include soup is missing and luakit wont compile correctly against it (classes/soup/soup.c), which I guess means luakit doesn't include it either(?). Regardless, including it somewhere (in my case; libwebkit) fixes the problem, but perhaps if libwebkit is removing inclusion from newer versions [>=1.3.10] (possibly leaving it up to the developers) then it may be needed in luakit. This is just speculation, though.

That is very weird indeed, could you pastebin the failed compile output (I'll see if there is anything we can do on our end) and if you have clang installed could you try `CC=clang make`.

milomouse wrote:

mason.larobina wrote:
Added a `globals.load_etc_hosts` option to enable/disable loading of hostnames from /etc/hosts (for those of you with huge /etc/hosts files). Commit: 29875cc
Fantastic. This seems to help as far as initial speed when opening links. There's still a small delay but nothing like before, but I guess that's from checking what the link actually is before proceeding, or something.

I don't think this delay is from us, I did some tests and the longest it took to call the search_open function on my system was 0.00015 seconds. This delay could be from webkit/libsoup checking the uri against your almost million-line /etc/hosts file.

milomouse wrote:

Update: Sometimes when working edit fields (like this reply block), I'll right click to copy, paste, or select-all and it will freeze my window-manager. Open terminals still show life (such as mplayer statusline still moving as file plays) but I can't select anything or change focus or quit. I tried in different window-managers, too, also downgrading my current one to almost a year ago -- same results, so I'm guessing it's luakit-develop since it never happened on non-dev luakit. Thankfully I push all output to a log file, so maybe this can help.. not sure how much though. It will repeat this line about 30 times in the log file:
(luakit:5747): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
I typed that out manually because right clicking and pasting it would have froze my screen again (I tried posting this 2 times before).

Ok that is very serious, I'll have to look into it but I can't reproduce the problem on my end.

Army · 2011-03-09 01:34:49

mason.larobina wrote:

What you're really after is cookie domain whitelisting & blacklisting. I'll work on that today.

Ah, so that doesn't work right now? Ok, I'd be happy to test it. Thanks!!

mason.larobina · 2011-03-09 02:24:24

Army wrote:

mason.larobina wrote:
What you're really after is cookie domain whitelisting & blacklisting. I'll work on that today.
Ah, so that doesn't work right now? Ok, I'd be happy to test it. Thanks!!

I'll message you as soon as it's finished.

Last edited by mason.larobina (2011-03-09 02:24:48)

Army · 2011-03-09 09:09:57

Great, thanks a lot!

milomouse · 2011-03-09 18:14:57

mason.larobina wrote:

That is very weird indeed, could you pastebin the failed compile output (I'll see if there is anything we can do on our end) and if you have clang installed could you try `CC=clang make`.

Ok, this is without #include'ing libsoup in webkit, and using CC=clang.

clang -c classes/soup/soup.c -o classes/soup/soup.o
classes/soup/soup.c:133:24: warning: implicit declaration of function 'webkit_get_default_session' is invalid in C99
      [-Wimplicit-function-declaration]
    soupconf.session = webkit_get_default_session();
                       ^
classes/soup/soup.c:133:22: warning: incompatible integer to pointer conversation assigning to 'SoupSession *'
         (aka 'struct _SoupSession *') from 'int'
    soupconf.session = webkit_get_default_session();
                     ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.

This normally would have caused an error that stopped compiling but I guess with clang it keeps going on these warnings. I'm using this compiled version now. Hmm, noticed it doesn't error even without clang now. Did you include libsoup somewhere or change anything? It used to show an error in relation to libwebkit's webkitsoupauthdialog.h file but it doesn't anymore.

mason.larobina wrote:

I don't think this delay is from us, I did some tests and the longest it took to call the search_open function on my system was 0.00015 seconds. This delay could be from webkit/libsoup checking the uri against your almost million-line /etc/hosts file.

You're right, because if I remove everything but my localhost from /etc/hosts it opens immediately, but I don't see the delay in luakit-git (master), only in luakit-develop-git (develop). It's not a big delay but noticable (with /etc/hosts adblocking). I don't see the delay in jumanji or surf either, as far as webkit browsers go. But since I love luakit (and development's features) I may find an alternative to /etc/hosts, perhaps that adblock.lua file but that may counteract privoxy... also noticing it shows [privoxy] in my statusbar now. Nice. I'll try to come to find a happy medium here, so I guess this problem is solved on your side already. Now it's up to me to make some cut backs.

mason.larobina wrote:

(luakit:5747): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
Ok that is very serious, I'll have to look into it but I can't reproduce the problem on my end.

I wish I knew more about how to reproduce it. I booted up today and was checking the thread and it just froze while sitting here looking at the thread (no errors in log, though), as libwebkit compiled in another terminal just fine. I'll see about downgrading some things for the sake of stability. Maybe that will help, even though I like the bug fixes in libwebkit >= 1.3.10. I don't know much about that error though, is that even libwebkit related or do you know? Update: Apparently it's strongly right-click related.. it's like russian roulette when it comes to right-clicking for me. Not just in edit boxes, but right-clicking on pictures or anything. It doesn't happen all the time but still quite frequently. This time I got one to print out more information: http://pastebin.com/zRX7UeZT

Last edited by milomouse (2011-03-09 20:14:45)

milomouse · 2011-03-09 18:39:14

karottenreibe wrote:

milomouse wrote:
mason.larobina wrote:
Ok, there is now an option `follow.sort_labels` which when true sorts the follow labels (default's to true to avoid confusion). Commit: 6c4f224
Thanks, guys. This seems to help some, although I can't say I have the same abstractional mind as javascripters. I find myself delaying still to match a pattern in links, even though I already know what it is. Say if I'm going to follow 661 and there's no 66[2-$] I end up typing the hint too fast and have a left-over 1 in my command buffer. This is tolerable but, when helping the user type less, it causes me (one of these users) to delay more so I don't type too much and/or type each one slower than I normally would. Again, it may just be me.
Yeah, JS tends to stretch ones imagination^^
I added a simple fix here: c4357d1b4c7c
It ignores the keystrokes after a successful follow for 500ms (configure this value with follow.ignore_delay)
Would that solve your problem?

That solves the problem of left-over keystrikes in the command buffer, yes. Thanks for this! Although, and I may be old-fashioned in this sense, I still miss the 11 12 13 .. 98 99 100 101, etc. I really do like the idea of the current follow.lua but think it's personal taste and will revert to the old version (still saved on my external drive). It seems fast enough to me and hopefully there wont be too many changes in the future that prevents this older version from working correctly with luakit. Perhaps give users an option to choose how they want their hints to be shown? I know you have sort/resort but they still look jumbled to me, all these 3 digit numbers overlapping each other. If I'm only going to be typing 2 of these digits, why not just show two? If I see a hint that says "661" I want to type 661, not 66[ignored key 1]. By no means, any offense intended. I really love this project and the attentive detail everyone puts into it, and I know it's up to the developer's as far as final word goes. So if you decide to keep only this new way of hinting then that's your choice, and I'll keep quiet about it from now on. Thanks again for everything.

Last edited by milomouse (2011-03-09 20:25:16)

r6 · 2011-03-09 23:20:37

You're never going to please everyone with one style of link hinting. It needs to be configurable. I see 3 options:

1. Have configurable options in the follow.lua. (messy)
2. Completely separate follow.lua files that work differently. Choose which one to load in rc.lua.
3. Put the javascript into a separate follow.js file. Choose one in follow.lua.

To have separate follow.lua files (how it currently works), would it be best to move some of the code (the binds/theme stuff) out of follow.lua so it's not duplicated in the separate files?

mason.larobina · 2011-03-10 04:49:26

milomouse wrote:

mason.larobina wrote:
That is very weird indeed, could you pastebin the failed compile output (I'll see if there is anything we can do on our end) and if you have clang installed could you try `CC=clang make`.
Ok, this is without #include'ing libsoup in webkit, and using CC=clang.
clang -c classes/soup/soup.c -o classes/soup/soup.o
classes/soup/soup.c:133:24: warning: implicit declaration of function 'webkit_get_default_session' is invalid in C99
      [-Wimplicit-function-declaration]
    soupconf.session = webkit_get_default_session();
                       ^
classes/soup/soup.c:133:22: warning: incompatible integer to pointer conversation assigning to 'SoupSession *'
         (aka 'struct _SoupSession *') from 'int'
    soupconf.session = webkit_get_default_session();
                     ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.
This normally would have caused an error that stopped compiling but I guess with clang it keeps going on these warnings. I'm using this compiled version now. Hmm, noticed it doesn't error even without clang now. Did you include libsoup somewhere or change anything? It used to show an error in relation to libwebkit's webkitsoupauthdialog.h file but it doesn't anymore.

The webkit guys have re-included that libsoup include and I've re-arranged our includes to make sure that libsoup is included before webkitsoupauthdialog.h c8127e7

milomouse wrote:

mason.larobina wrote:
I don't think this delay is from us, I did some tests and the longest it took to call the search_open function on my system was 0.00015 seconds. This delay could be from webkit/libsoup checking the uri against your almost million-line /etc/hosts file.
You're right, because if I remove everything but my localhost from /etc/hosts it opens immediately, but I don't see the delay in luakit-git (master), only in luakit-develop-git (develop). It's not a big delay but noticable (with /etc/hosts adblocking). I don't see the delay in jumanji or surf either, as far as webkit browsers go. But since I love luakit (and development's features) I may find an alternative to /etc/hosts, perhaps that adblock.lua file but that may counteract privoxy... also noticing it shows [privoxy] in my statusbar now. Nice. I'll try to come to find a happy medium here, so I guess this problem is solved on your side already. Now it's up to me to make some cut backs.

I still don't understand what is causing the delay here if you've disabled the /etc/hosts loading (given that you said it didn't have this delay in luakit-git).

Edit: The checking if the file is a filepath could be causing the delay. I use SSD drives so I wouldn't notice it. I've added a `check_filepath` to the top of config/globals.lua. See if that helps.

milomouse wrote:

mason.larobina wrote:
(luakit:5747): Gtk-CRITICAL **: IA__gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
Ok that is very serious, I'll have to look into it but I can't reproduce the problem on my end.
I wish I knew more about how to reproduce it. I booted up today and was checking the thread and it just froze while sitting here looking at the thread (no errors in log, though), as libwebkit compiled in another terminal just fine. I'll see about downgrading some things for the sake of stability. Maybe that will help, even though I like the bug fixes in libwebkit >= 1.3.10. I don't know much about that error though, is that even libwebkit related or do you know? Update: Apparently it's strongly right-click related.. it's like russian roulette when it comes to right-clicking for me. Not just in edit boxes, but right-clicking on pictures or anything. It doesn't happen all the time but still quite frequently. This time I got one to print out more information: http://pastebin.com/zRX7UeZT

Do you have an old webkit version (maybe 1.2.7) lying around? Nobody else has reported this problem I'm trying to figure out what's different about your system.

Last edited by mason.larobina (2011-03-10 06:30:25)

mason.larobina · 2011-03-10 05:05:01

milomouse wrote:

karottenreibe wrote:
milomouse wrote:
Thanks, guys. This seems to help some, although I can't say I have the same abstractional mind as javascripters. I find myself delaying still to match a pattern in links, even though I already know what it is. Say if I'm going to follow 661 and there's no 66[2-$] I end up typing the hint too fast and have a left-over 1 in my command buffer. This is tolerable but, when helping the user type less, it causes me (one of these users) to delay more so I don't type too much and/or type each one slower than I normally would. Again, it may just be me.
Yeah, JS tends to stretch ones imagination^^
I added a simple fix here: c4357d1b4c7c
It ignores the keystrokes after a successful follow for 500ms (configure this value with follow.ignore_delay)
Would that solve your problem?
That solves the problem of left-over keystrikes in the command buffer, yes. Thanks for this! Although, and I may be old-fashioned in this sense, I still miss the 11 12 13 .. 98 99 100 101, etc. I really do like the idea of the current follow.lua but think it's personal taste and will revert to the old version (still saved on my external drive). It seems fast enough to me and hopefully there wont be too many changes in the future that prevents this older version from working correctly with luakit. Perhaps give users an option to choose how they want their hints to be shown? I know you have sort/resort but they still look jumbled to me, all these 3 digit numbers overlapping each other. If I'm only going to be typing 2 of these digits, why not just show two? If I see a hint that says "661" I want to type 661, not 66[ignored key 1]. By no means, any offense intended. I really love this project and the attentive detail everyone puts into it, and I know it's up to the developer's as far as final word goes. So if you decide to keep only this new way of hinting then that's your choice, and I'll keep quiet about it from now on. Thanks again for everything.

That was karottenreibe's motive for moving the `make_labels(size)` function out of the following javascript and into Lua (so that we could swap it out easily and or make modifications easily).

For example I've just pushed a commit which adds a `follow.reverse_labels` option here. As usual just add `follow.reverse_labels = false` (and or `follow.sort_labels = false`) to your rc.lua after the follow require.

Edit: Sorry guys I've just fixed a build error in the develop branch, try again.

Last edited by mason.larobina (2011-03-10 06:20:59)

Army · 2011-03-10 11:02:32

Little problem here:

I have

awe         = "https://wiki.archlinux.org/index.php?title=Special%3ASearch&search=%s",

in my globals.lua to quickly search in the Arch-Wiki.
When I type

:open awe luakit

I get

:Error: In comand call: /etc/xdg/luakit/binds.lua:265 invalid option '%A' to 'format'

How can I solve this? Going back to {0} instead of %s is problematic afair, because it breaks stuff.

quigybo · 2011-03-10 12:24:15

@Army: this is caused by changing from string.gsub to string.format in search_open (commit 3fc47c30), which breaks on percent-encoded uri's. For more info see this list posting and commit 11b2bd14.

tl;dr, escape (%%) unrelated percent characters.

Army · 2011-03-10 15:41:42

Thanks quigybo!

milomouse · 2011-03-10 18:21:19

mason.larobina wrote:

I still don't understand what is causing the delay here if you've disabled the /etc/hosts loading (given that you said it didn't have this delay in luakit-git).
Edit: The checking if the file is a filepath could be causing the delay. I use SSD drives so I wouldn't notice it. I've added a `check_filepath` to the top of config/globals.lua. See if that helps.

Well, I also have SSDs on a quad-core (2.1) system with 12GB of RAM, so that wasn't the problem. Apparently all my problems are revolving around newer versions of webkit. Yes, I know they're considered developmental so this is to be expected but I just found it strange that my only problems were when using luakit-develop-git, no other webkit browsers. Perhaps it's due to code depth and complexity; luakit has come a long way compared to most others. Regardless, downgrading libwebkit and libsoup to current "repo stables" seems to be working ATM. I don't see a delay anymore with hosts disabled and check_filepath enabled (or disabled). Also, I've been right-clicking different pages and elements like crazy and so far no crash.

mason.larobina wrote:

That was karottenreibe's motive for moving the `make_labels(size)` function out of the following javascript and into Lua (so that we could swap it out easily and or make modifications easily).
For example I've just pushed a commit which adds a `follow.reverse_labels` option here. As usual just add `follow.reverse_labels = false` (and or `follow.sort_labels = false`) to your rc.lua after the follow require.

Allright, setting both of these to false helps a great deal. Everything else is also working as expected and will report otherwise. I just want to thank you guys for everything, muchly appreciated, especially considering how much of a nuisance I've been. At least we learned and applied some things along the way.

Side notes:
1) I noticed assigning a user download folder is now exclusively in downloads.lua(?) lib instead of globals.lua. User needs to edit the lib file to change this or can it be reassigned in globals.lua?
2) By no means a problem, just thought I'd let you know that "$" is defined twice in binds.lua.
3) Also noticed add_cmds for quit[..] have left downloads.lua, so assigning them in binds.lua seems to work again (a previous situation we discussed). I'm now able to check tabcount and use "q" to close tab > 1 else quit. Thanks.

Last edited by milomouse (2011-03-10 18:23:15)

SuNjACk · 2011-03-10 18:35:41

Are .gif files working on the develop version of luakit (on AUR luakit-develop-git)?pc

Last edited by SuNjACk (2011-03-10 18:43:46)

milomouse · 2011-03-10 19:11:34

SuNjACk wrote:

Are .gif files working on the develop version of luakit (on AUR luakit-develop-git)?pc

i think it depends on what version of libwebkit you have, if you mean gifs flickering, etc.

mason.larobina · 2011-03-11 02:25:44

milomouse wrote:

mason.larobina wrote:
I still don't understand what is causing the delay here if you've disabled the /etc/hosts loading (given that you said it didn't have this delay in luakit-git).
Edit: The checking if the file is a filepath could be causing the delay. I use SSD drives so I wouldn't notice it. I've added a `check_filepath` to the top of config/globals.lua. See if that helps.
Well, I also have SSDs on a quad-core (2.1) system with 12GB of RAM, so that wasn't the problem. Apparently all my problems are revolving around newer versions of webkit. Yes, I know they're considered developmental so this is to be expected but I just found it strange that my only problems were when using luakit-develop-git, no other webkit browsers. Perhaps it's due to code depth and complexity; luakit has come a long way compared to most others. Regardless, downgrading libwebkit and libsoup to current "repo stables" seems to be working ATM. I don't see a delay anymore with hosts disabled and check_filepath enabled (or disabled). Also, I've been right-clicking different pages and elements like crazy and so far no crash.

That's awesome news, you might like to add a webkit-gtk bug-report for the problem to make sure it is fixed/looked at before it's next release.

milomouse wrote:

mason.larobina wrote:
That was karottenreibe's motive for moving the `make_labels(size)` function out of the following javascript and into Lua (so that we could swap it out easily and or make modifications easily).
For example I've just pushed a commit which adds a `follow.reverse_labels` option here. As usual just add `follow.reverse_labels = false` (and or `follow.sort_labels = false`) to your rc.lua after the follow require.
Allright, setting both of these to false helps a great deal. Everything else is also working as expected and will report otherwise. I just want to thank you guys for everything, muchly appreciated, especially considering how much of a nuisance I've been. At least we learned and applied some things along the way.
Side notes:
1) I noticed assigning a user download folder is now exclusively in downloads.lua(?) lib instead of globals.lua. User needs to edit the lib file to change this or can it be reassigned in globals.lua?

Likewise just add `download.default_dir = "/your/path/here"` to your rc.lua after the "downoads" require. No need to copy the lib over.

milomouse wrote:

2) By no means a problem, just thought I'd let you know that "$" is defined twice in binds.lua.

Thanks, fixed.

milomouse wrote:

3) Also noticed add_cmds for quit[..] have left downloads.lua, so assigning them in binds.lua seems to work again (a previous situation we discussed). I'm now able to check tabcount and use "q" to close tab > 1 else quit. Thanks.

Yeah no problem, It's something I should have done a while ago but it slipped my mind. But to fix it correctly I've added support for command bang syntax (I.e. ":cmd! <args>") that way we can force quit (with :q!/:wq!) without defining the :q or :wq binds twice. It took a few changes here and there but I think it works really well now.

And keep the messages coming, this sort of critical analysis of the configs/code is great and just what luakit needs to make it better.

karottenreibe · 2011-03-11 08:43:33

milomouse wrote:

mason.larobina wrote:
That was karottenreibe's motive for moving the `make_labels(size)` function out of the following javascript and into Lua (so that we could swap it out easily and or make modifications easily).
For example I've just pushed a commit which adds a `follow.reverse_labels` option here. As usual just add `follow.reverse_labels = false` (and or `follow.sort_labels = false`) to your rc.lua after the follow require.
Allright, setting both of these to false helps a great deal. Everything else is also working as expected and will report otherwise. I just want to thank you guys for everything, muchly appreciated, especially considering how much of a nuisance I've been. At least we learned and applied some things along the way.

If you're still not 100% satisified, you can always replace that make_lables function in your rc.lua after the follow.lua require and just return an array that fits your preference. There's no special magic involved, just return an array with the given number of strings in it and they will be used in hinting.

And you haven't been a nuisance at all It's always good to get some feedback, especially when I do big changes like this. You never know if you're going in the right direction if noone tells you^^

milomouse · 2011-03-11 17:44:28

mason.larobina wrote:

That's awesome news, you might like to add a webkit-gtk bug-report for the problem to make sure it is fixed/looked at before it's next release.

Yeah, so far so good, except a few webkit annoyances such as the gif thing. Will still experiment with newer versions but report any problems incurred thereafter to webkit since this seems to be the root of the problem and not luakit, thank goodness. I'll see about that bug report soon.
Update: Seems there's a fix for the gifs now, as pointed out by bangkok_manouel: http://gitorious.org/webkitgtk/stable/c … e69c73f6cd

mason.larobina wrote:

Likewise just add `download.default_dir = "/your/path/here"` to your rc.lua after the "downoads" require. No need to copy the lib over.

Ok, that makes sense. Thanks.

mason.larobina wrote:

milomouse wrote:
3) Also noticed add_cmds for quit[..] have left downloads.lua, so assigning them in binds.lua seems to work again (a previous situation we discussed). I'm now able to check tabcount and use "q" to close tab > 1 else quit. Thanks.
Yeah no problem, It's something I should have done a while ago but it slipped my mind. But to fix it correctly I've added support for command bang syntax (I.e. ":cmd! <args>") that way we can force quit (with :q!/:wq!) without defining the :q or :wq binds twice. It took a few changes here and there but I think it works really well now.
And keep the messages coming, this sort of critical analysis of the configs/code is great and just what luakit needs to make it better.

Yeah I saw that, and I think it's great. I meant to mention that afterwards, noticing the (o.bang)'s and tracking it up to that line of code in the binds [and appears it's linked through those other files as well]; I believe it a very elegant manner of culling and refining. Good deal, and thanks. I've been a little side-tracked lately but am getting back into examining the code so I'll pip up if I see and/or think of anything else.

Edit:
1) By the way, I noticed the [+] for history earlier on (in the statusbar), but now I notice a [+-] sometimes, too. What's the - ?
2) Not sure if this was discussed before, but is there a way to communicate with an open luakit instance, say.. from a terminal, open a link in a new tab (in already open luakit) rather than `luakit $URI' opening another luakit instance?

Last edited by milomouse (2011-03-11 19:25:26)

milomouse · 2011-03-11 17:53:17

karottenreibe wrote:

If you're still not 100% satisified, you can always replace that make_lables function in your rc.lua after the follow.lua require and just return an array that fits your preference. There's no special magic involved, just return an array with the given number of strings in it and they will be used in hinting.
And you haven't been a nuisance at all It's always good to get some feedback, especially when I do big changes like this. You never know if you're going in the right direction if noone tells you^^

As it stands right now, for numeric, I like how it displays when they're both set to false so I don't feel I need to tweak that aspect. Thanks again for that. I'll take a closer look, do some experimenting, and see about that alphabetic version I was musing over earlier on.. :}

mason.larobina · 2011-03-12 00:45:55

milomouse wrote:

1) By the way, I noticed the [+] for history earlier on (in the statusbar), but now I notice a [+-] sometimes, too. What's the - ?

+ can go back, - can go forward, +- can go forward or back (same as in vimperator & jumanji)

milomouse wrote:

2) Not sure if this was discussed before, but is there a way to communicate with an open luakit instance, say.. from a terminal, open a link in a new tab (in already open luakit) rather than `luakit $URI' opening another luakit instance?

There is no way to do this at the moment in the official repo but husio has a dbus branch which allows opening of links in a new tab in running instances.

Last edited by mason.larobina (2011-03-12 02:51:19)

Arch Linux

#226 2011-03-08 17:55:38

Re: luakit browser framework (almost with jQuery!)

#227 2011-03-08 18:49:01

Re: luakit browser framework (almost with jQuery!)

#228 2011-03-08 19:12:15

Re: luakit browser framework (almost with jQuery!)

#229 2011-03-08 19:57:54

Re: luakit browser framework (almost with jQuery!)

#230 2011-03-08 22:56:23

Re: luakit browser framework (almost with jQuery!)

#231 2011-03-08 23:54:51

Re: luakit browser framework (almost with jQuery!)

#232 2011-03-09 01:34:49

Re: luakit browser framework (almost with jQuery!)

#233 2011-03-09 02:24:24

Re: luakit browser framework (almost with jQuery!)

#234 2011-03-09 09:09:57

Re: luakit browser framework (almost with jQuery!)

#235 2011-03-09 18:14:57

Re: luakit browser framework (almost with jQuery!)

#236 2011-03-09 18:39:14

Re: luakit browser framework (almost with jQuery!)

#237 2011-03-09 23:20:37

Re: luakit browser framework (almost with jQuery!)

#238 2011-03-10 04:49:26

Re: luakit browser framework (almost with jQuery!)

#239 2011-03-10 05:05:01

Re: luakit browser framework (almost with jQuery!)

#240 2011-03-10 11:02:32

Re: luakit browser framework (almost with jQuery!)

#241 2011-03-10 12:24:15

Re: luakit browser framework (almost with jQuery!)

#242 2011-03-10 15:41:42

Re: luakit browser framework (almost with jQuery!)

#243 2011-03-10 18:21:19

Re: luakit browser framework (almost with jQuery!)

#244 2011-03-10 18:35:41

Re: luakit browser framework (almost with jQuery!)

#245 2011-03-10 19:11:34

Re: luakit browser framework (almost with jQuery!)

#246 2011-03-11 02:25:44

Re: luakit browser framework (almost with jQuery!)

#247 2011-03-11 08:43:33

Re: luakit browser framework (almost with jQuery!)

#248 2011-03-11 17:44:28

Re: luakit browser framework (almost with jQuery!)

#249 2011-03-11 17:53:17

Re: luakit browser framework (almost with jQuery!)

#250 2011-03-12 00:45:55

Re: luakit browser framework (almost with jQuery!)

Board footer