[HN Gopher] Qutebrowser: A keyboard-driven, Vim-like browser
___________________________________________________________________
Qutebrowser: A keyboard-driven, Vim-like browser
Author : AbuAssar
Score : 124 points
Date : 2024-12-08 12:06 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sylware wrote:
| Please, tackle the _real_ issue: we need an implementation of a
| modern 'web browsers' using a 'simple computer language' (for
| instance C99+, namle C99 with few bits of c11 for modern
| architecture programming).
| dotancohen wrote:
| I understand the sentiment, but who are the "we" who "need"
| that?
| sylware wrote:
| Humanity, not AI bots.
| bramhaag wrote:
| Why do "we" need this?
| ramon156 wrote:
| Because "we" need a browser that doesn't need a rewrite in
| the next 20 years
| sylware wrote:
| big tech is evily smart: since everything is open source,
| they are still doing vendor lock-in via grotesque and
| absurd complexity and size, breaking little things here and
| there, or using unspecified part which is "implementation
| defined" etc. Not seeing that is borderline blindless than
| a lack of perspective.
|
| Open source is far from being enough anymore, we (the
| humanity) need lean open source (including that bloody SDK,
| which excludes de-facto ultra-complex computer language
| like c++/rust/java/etc).
| sylware wrote:
| See above.
| orbisvicis wrote:
| Don't forget lisp! This is particularly relevant because of the
| Nyxt browser which was also recently posted here.
|
| https://en.m.wikipedia.org/wiki/Lisp_machine
|
| Also c23 is supposed to have better unicode support but I've
| never really bothered internalizing the "translation character
| set" and whatnot.
| sylware wrote:
| Come on, this was about the language syntax, not some
| external massive util library. Ofc, this web engine would
| implement mostly its own utils, since dependency on external
| kludge like unistring or ICU or even worse harfbuzz(c++!)...
| would nullify the advantage to depend on a simple computer
| language.
|
| I did not look that much into it but I can bet that 'lisp'
| browser is actually just a 'lisp front-end' to big tech web
| engines... namely a scam, please prove me wrong.
|
| I would write a browser in RISC-V assembly with a small macro
| pre-processor, but the issue with the web is its infinite
| scope killing any non big tech, real-life, alternative
| attempt, and not for the good reasons.
| ComputerGuru wrote:
| Who is "we" and why do we need it in a "simple" language prone
| to memory errors where people have to non-portably reinvent
| every wheel?
|
| Signed,
|
| someone that writes and distributes apps/tools written in "less
| simple" languages and apps/tools written in zero-dependency and
| even libc-free C.
| sourcepluck wrote:
| Nyxt already exists, and fits your description perfectly
| sylware wrote:
| Indulge me and let me be lazy and answer this question: Is
| Nyxt _NOT_ just a front-end to one of the Big Tech web
| engines? (blink|geeko|webkit)
|
| I would be super pleased to be wrong...
| sourcepluck wrote:
| Oh sorry, just realised I replied to my own comment instead
| of yours :D see my response above!
| sourcepluck wrote:
| Nyxt is basically a front-end to the Big Tech web engines,
| yes, but one that (I think sincerely, from my not-overly-
| technical standpoint) attempts to re-empower the user.
|
| I didn't understand your original point about needing "a
| modern web browser" with "a simple language" (I'm not sure it
| was clear, by itself...), but I read your other comments, and
| I understand your point better now, I think.
|
| I agree that "open source" itself is absolutely not enough,
| and that another prerequisite to fighting for practical
| computing freedom is to have "human"-sized tools. Fully on
| board with that (I wonder if you've seen the malleable
| systems forum, actually...).
|
| I think Nyxt would love to provide that, eventually, and are
| trying to fight that fight, on a stacked battleground, in an
| imperfect world.
|
| For example, gopher and gemini are supported. And they're
| trying to support different renderers. They're trying to make
| the browser fully configurable and programmable as far as
| they can, in spite of the shortcomings of the web.
|
| Tell me if this is completely beside your point, but in case
| it helps you in seeing what they're about, have a look at:
|
| https://nyxt-browser.com/article/command-line-programs.org
|
| Or, much more technical, too technical for me, and it's a bit
| dated so the exact design might have changed, but maybe
| you'll get something from the overview nonetheless:
|
| https://nyxt-browser.com/article/technical-design.org
|
| Maybe that's not enough, and you think the solution has to be
| more radical, but I don't know what it would be, other than a
| new set of networking protocols comes along and somehow
| supercedes the ones we have now. Which could happen, I don't
| know, I'm only still only learning about the ones we
| currently have :D
|
| Also, have you seen surfraw? Or do you have examples of the
| kind of thing you'd like to see being attempted in the wild?
| I'd be curious to see them.
|
| p.s. I responded to a point you made 8 days ago about email
| in a different thread
| [https://news.ycombinator.com/item?id=42287607] and thought
| I'd say to you here in case you'd be interested in
| elaborating over there!
| sylware wrote:
| This was a ironic comment: the grotesque and absurd
| complexity and size of a Big Tech engine (google
| blink/geeko | apple webkit) with their SDK (c++ compilers,
| gcc/clang) kill any "real-life" attempt at interop. You
| would need many, MANY good devs, for a significant amount
| of time to maybe acheive 'real-life' compatibility in,
| pheeew, some significant amount of time... if ever... And
| even when you get something "working", don't forget they
| control also the online services requiring their pieces of
| software... namely those guys will have to play cat and
| mouse about interop: permanent little changes on Big Tech
| services (more or less justified) and Big Tech web engines,
| breaking any other alternatives... I think you get the
| picture.
|
| And that is exactly the same issue with the c++ language
| syntax and its compilers (that would be the same issue with
| other complex computer languages like rust/java/etc).
|
| Seriously, I would go for a modular implementation directly
| in 64bits RISC-V assembly with a very small macro-
| preprocessor (because, moving the complexity from the
| language syntax to the macro-preprocessor would be
| riduculous).
|
| That's why, from this perspective, those small attempts are
| kind of pointless and even somewhat dishonnest since, in
| the end/'real-life', they are just font-ends of Big Tech...
|
| The email people did see the DNS "barrier" coming: it has
| always supported literal IPv4 addresses (and a similar IPv6
| literal has been in specs for ages).
|
| Using the "excuse" of spam/phishing of script kiddies, they
| blocked IPv4 literal support and ignored the subsequent
| IPv6 literal support. If I recall well, IPv4 literal
| support was a thing on google mail a few years ago (even
| IPv6 if I recall properly), it means it was explicitely
| blocked.
|
| Then to get SMTP interop with them: you MUST rent/pay for a
| domain name, and in the last few years, very slowly but
| surely (I did live it, horrible), the DNS registars did
| stop working without a Big Tech web engine (they were
| working fine with lynx or links or netsurf, namely
| noscript/basic (x)html, which is more than enough, actually
| even overkill).
|
| Basically, they have big services, and they made sure that,
| slowly and in the end, you must use their software for
| their services, and they could not careless of the small
| alternatives even if the internet protocols did account for
| this. This is compuserve/AOL all over again. The
| remaining/surviving "small" did just cave in and is part of
| the problem now.
|
| The only sane way out of this "dominance" is to restore
| interop with simple , but good enough to do the job, and
| really stable in time protocols. And restoring 'interop'
| won't happen asking nicely: only hardcore _technical_
| regulation can do it now.
|
| All is about technical interfaces: the very hard part is
| they must be simple and stable in time, _while doing a good
| enough job_. Ofc, things may significantly change,
| significant new usages can arise... then new simple and
| stable in time technical interfaces will have to be
| designed (but one or a small number of average devs should
| get it implemented in a reasonable amount of time), or new
| simple and stable in time "layers" added an an existing
| technical interface (the core of the dynamic web is
| noscript with basic (x)html forms, and I think it is
| already way too complicated). A set of layered and modular
| technical interfaces, but all simple and stable in time.
| Ofc, if there are billions of interfaces required to
| support a basic use case, there is something wrong
| somewhere...
|
| I did reach a point where I would not be even surprised if
| they did shadow-pay hackers to bring down any simple and
| stable alternatives.
|
| It far from easy to deal with all of this.
| graiz wrote:
| Chrome extension - vimium does the same thing. I've been using it
| for years.
| bramhaag wrote:
| Qutebrowser fixes the main issue I have with Vimium: you cannot
| control the browser itself well. Vimium does not work in
| certain places due to limitations imposed by web extensions and
| this is incredibly frustrating for me.
| Timothee wrote:
| I've used both for many years. I've stopped using qutebrowser
| because it has some limitations due to be a bit behind on the
| web engine, which leads to problems with some sites. I still
| think it's brilliant.
|
| I wouldn't say they do the same thing exactly. Vimium is
| similar to a vim-mode in something like VS Code, while
| qutebrowser is more like Vim itself. The Vim "spirit" is built-
| in and is the expectation rather than a layer added on top. The
| qutebrowser UI, already minimalistic, is also very configurable
| and scriptable.
|
| The flip side to me is that some of the experience will be
| nicer with Chrome, the same way VS Code can be nicer and easier
| to manage.
| porphyra wrote:
| Configuring the qutebrowser UI is a major reason I used
| qutebrowser for some years. I love ricing my system and
| saving screen real estate with a minimal UI bloat is nice.
| The-Compiler wrote:
| > I've stopped using qutebrowser because it has some
| limitations due to be a bit behind on the web engine, which
| leads to problems with some sites.
|
| Assuming you're on Linux, that's usually more of a problem
| with Linux distributions being behind on QtWebEngine. Though
| yeah, sometimes things are tight with QtWebEngine only
| updating their Chromium baseline once every 6 months. I try
| to ship workarounds (in the form of polyfills) with
| qutebrowser when I know about breakage, but usually for me
| things run smoothly.
| Timothee wrote:
| No, I'm on macOS. I think my main issue was with videos
| that didn't always play correctly. Can't remember exactly
| but I think either on Reddit or Twitter, it was just not
| reliable.
| The-Compiler wrote:
| Ah, I see. That's not due to the Chromium version though,
| it's because the Chromium that comes with Qt releases
| (which is what's shipped in qutebrowser releases) is
| built without proprietary codec support.
|
| Unfortunately, support for proprietary codecs like MP4
| and such requires building Qt from sources, and would
| also require me to acquire licenses for them all (I
| believe they're free until a certain number of
| distributions, but also with all the indirect ways you
| can get qutebrowser, I can hardly even provide that
| information).
|
| This isn't an issue on Linux, because those licenses have
| some sort of exception in the sense of "if shipped with
| an operating system or its packages".
|
| Homebrew seems to build its Qt packages against system
| ffmpeg with proprietary codecs enabled, and there's an
| issue open which would at least allow you to build a
| custom build against that:
| https://github.com/qutebrowser/qutebrowser/issues/4127
|
| Maybe I should look into whether I'd be allowed to
| redistribute such builds (or what kind of paperwork I'd
| need to do for it). Unfortunately there's a lot on my
| plate, and macOS/Windows are admittedly somewhat second-
| class citizens as I don't use those myself.
| lillesvin wrote:
| Been using Vimium for years too and it's great, but it's really
| not the same. The late, great Vimperator extension was more
| comparable to QuteBrowser but it stopped functioning (on
| Firefox) when they switched from XUL to web extensions.
|
| Vimium mainly gives you keyboard navigation, but QuteBrowser
| removes the address, tab and bookmark bars and instead gives
| you keyboard access to everything via the very Vim-like status
| bar at the bottom. Incidentally this also frees up quite a bit
| of vertical screen real estate, which is a big deal to me.
| Browser settings, scripts, etc. are also all accessible via the
| keyboard -- Vim style.
|
| Edit: The lack of a solid Bitwarden integration in QuteBrowser
| is kind of hurting though.
| dijit wrote:
| I really enjoy using qutebrowser.
|
| It's a shame that I often end up using more than 100GiB of RAM
| with a few dozen tabs, almost like it leaks memory. I'm aware of
| the inherent fragmentation of memory with python over time- so
| could be that.
|
| There's also been a few times where the limitations of using
| qtwebengine (chromium wrapper) underneath were frustrating -
| though I can barely remember what they are at this point.
|
| The python config is great too, I use it to disable javascript
| conditionally. :)
|
| Theres also some magic feeling when pressing "o" and having
| access to the world.
| cma wrote:
| Was it 100GiB of RAM, or 100GiB of forked processes sharing
| lots of memory pages? Python reference counting destroys forked
| process sharing, but only for the the Python parts.
| dijit wrote:
| actual usage, 100G of resident memory.
| shimonabi wrote:
| When I tried to install the Windows release, I got a message that
| it contains the Vigram.A virus.
| The-Compiler wrote:
| See https://github.com/qutebrowser/qutebrowser/issues/8389 -
| unfortunately there's a lot of stupid false-positives
| especially with PyInstaller (packaging a Python application
| into an .exe). Happens a few times a year, unfortunately there
| isn't much I can do other than submitting a report to Microsoft
| and hoping they'll react -\\_(tsu)_/-
| _kst_ wrote:
| I got the same thing and worked around it by installing the
| previous release.
| shubhamkrm wrote:
| Oh! This takes me back. I used it as my primary browser during
| the Firefox 57 saga, and continues to use it for over an year.
| The developer was very responsive to bug reports, and fixed the
| issues right away. Unfortunately, I moved away from the Linux
| ecosystem as my primary computing environment, but I would still
| recommend this if someone wants to try a Vim-based browsing
| experience and is willing to try out a new browser.
| The-Compiler wrote:
| FWIW there are Windows/macOS builds too.
| JadeNB wrote:
| > I used it as my primary browser during the Firefox 57 saga
|
| As an early lover of Firefox, I'm sorry to see its progression
| away from its ideals, and can't keep track of which part of the
| saga happened when. Was that when they removed XUL?
| iLoveOncall wrote:
| How is this not extremely inefficient to use? I guess you can use
| the "hints" as shown in
| https://github.com/qutebrowser/qutebrowser/blob/main/doc/img...
| but this is such a poor experience I can't fathom someone wanting
| this.
|
| All browsers already support keyboard shortcuts for 90% of the
| common browser operations (next / previous page, focusing the
| address bar, etc.), and anything on the page itself seems like a
| massive chore (except scrolling, which browsers also support).
| IshKebab wrote:
| My theory is that some people see use of a mouse as a sign of
| noobery - which is true in some cases! Who do you think is more
| pro - the person who clicks Edit->Copy, or the person who
| clicks Ctrl-C?
|
| So their lizard brain thinks "mouse=stupid, keyboard=smart" and
| then they optimise for a sense of superiority.
| vunderba wrote:
| Or you know could be:
|
| - a user who prefers to minimize switching from mouse to
| keyboard, or vice versa
|
| - a user who has some RSI issues related to the index finger
| when clicking a mouse
|
| etc. etc.
|
| But no, let's go with the deliberately antagonistic strawman.
| nosioptar wrote:
| I prefer the keyboard due to severe tendonitis in my wrist
| and arthritis in my hands. I can use a keyboard all day with
| no problem. A few hours with a mouse leaves me all swollen
| and in pain.
| IshKebab wrote:
| I used to get what I _thought_ was RSI. I mean it _was_
| RSI. I tried all sorts of weird keyboards and mice (don 't
| bother with vertical mice, they suck).
|
| What it turned out to be in the end was a poor desk setup.
| My desk wasn't deep enough so I wasn't resting my forearms
| on it very well, and I had a crap chair.
|
| With a deep desk and a fancy mesh chair (HM Mira; expensive
| but worth it), I haven't had any issues since.
|
| Maybe that's not the case for you but it's just a
| suggestion. Definitely made me suss of all the ergonomic
| keyboards and mouse - they made zero difference, and a
| better chair and desk completely solved the issue.
| mariusor wrote:
| I wonder why you'd imagine that ergonomic input devices
| would solve a problem with your seating arrangement? I
| think generally they solve issues that are left after
| posture has been fixed.
| IshKebab wrote:
| Here, I'll highlight the bit you missed:
|
| > _What it turned out to be in the end_
| mariusor wrote:
| I was probably fixated on this:
|
| > Definitely made me suss of all the ergonomic keyboards
| and mouse
| jwiz wrote:
| Switching back and forth between keyboard and mouse is a
| pain. I used QB a lot at my last job but current one has too
| many things which need passwords entered frequently so I am
| reduced to vimium and chrome.
| greggyb wrote:
| If you are looking at a link you want to follow, you press a
| single hotkey (default 'f'), and just type the two letters that
| appear directly where you're looking. If you want to open a lot
| of links in the background, e.g. if you're looking at the front
| page of HN, you can use the rapid follow action (default ';r')
| and just type a couple letters for each link you'd like to
| follow.
|
| Personally, this is much easier on my RSI than mousing to each
| link. Especially on a laptop with a trackpad.
|
| Additionally, the browser is fully configurable in Python, to a
| much greater degree than what you get from Firefox or Chrome.
|
| One seemingly small thing that I find quite convenient is that
| I can use reader mode or open a PDF and still keep hjkl for
| scrolling. I also use Tridactyl in Firefox, but Firefox's
| reader mode and opening PDFs turns disable extensions in the
| tab, so you can't use these scrolling keys.
|
| As for next and previous page, I think you're referring to
| history navigation forward and back. Qutebrowser includes
| built-in functionality to navigate in multi-page documents to
| the next page and previous page, e.g. documentation sites or
| html books. That shortcut is '[[' for previous and ']]' for
| next. So, for example, if I am on this section of SICP:
| https://sarabander.github.io/sicp/html/1_002e3.xhtml#g_t1_00...
| and I press ']]' I immediately go to
| https://sarabander.github.io/sicp/html/Chapter-2.xhtml#Chapt...
| . This happens regardless of browser history. "Back" and
| "Forward" are different from "Previous" and "Next". I do not
| know of a similar piece of functionality in other mainstream
| browsers.
|
| This is all highly opinionated. I like vim-style shortcuts. I
| vastly prefer the experience of using qutebrowser (or a vim-
| like extension for another browser) over using a mouse
| exclusively or a mouse and keyboard mixed.
|
| If you, or someone else, prefers a different style of
| interaction with the browser, that's fine. It's not about right
| or wrong or better and worse, at least not in the abstract.
| It's about a user interaction paradigm that works well for an
| individual.
| bovine3dom wrote:
| FWIW I got some of the way through embedding a PDF viewer in
| Tridactyl [1] so that the keys would still work there, but I
| backed off because I was a bit scared by how frequently
| pdf.js gets updated. In Tridactyl it'd get updated about
| twice a year so we might end up with unresolved security
| issues.
|
| Maybe there's a solution I've not thought of (CDN?).
|
| [1] https://github.com/tridactyl/tridactyl/issues/541#issueco
| mme...
| Izkata wrote:
| > press a single hotkey (default 'f'), and just type the two
| letters that appear directly where you're looking
|
| This has a mental speed bump that I really don't like, that
| tends to make these features annoying to use: you have to
| pause after hitting "f" to wait for those letters to appear,
| read them, then type them.
|
| Vimperator (the one that died with Firefox Quantum) handled
| links where you'd hit "f" then type the text in the link
| itself, with numbers to disambiguate if the filtering didn't
| reduce it to one match. With no pause and the link text
| already in your mind by the time you hit "f" it was very fast
| and fluid to use, and I was very happy after learning
| Tridactyl could be configured the same way.
|
| Does this have the same thing?
| mariusor wrote:
| Yes, it does: set hint.mode numbers.
|
| I don't remember if it's explained anywhere that once
| hinting is started you can filter based on link text, alt
| text, or a couple of other textual representations for
| clickable elements.
| ykonstant wrote:
| I tried really hard with QB, and still use it for some tasks, but
| the lack of Ublock Origin makes browsing random sites horrible.
| People say the builtin ad blockers are good enough; for me, they
| are not even remotely good enough :(
| alrs wrote:
| I've had good results running alt-browsers behind Privoxy.
|
| https://www.privoxy.org/
| dalai wrote:
| It is a real pity that the major browsers don't support better
| keyboard navigation out of the box. Due to work restrictions, I
| can only really use firefox, chrome or edge and no
| addons/extensions. There's a 14 year old ticket for firefox
| (still open), but the reaction back then was that it is a niche
| feature better suited for an addon.
| monroewalker wrote:
| I tried an extension once that provided these navigation
| shortcuts for all the links on a page. It was really convenient
| but then I was on an admin page for our team and accidentally hit
| a couple keys that pressed some random button. The page was full
| of buttons that had irreversible effects which were executed
| without confirmation. Of course that's an issue itself for the
| page but that's kept me from trying this again.
|
| The convenience those shortcuts provide also makes it
| concerningly easy to press something on accident. Much more
| likely than accidentally clicking something. Having extra leader
| keys or some other approach to reduce accidental presses would
| detract from the convenience...
|
| Curious if anyone else has run into this or configured their
| setup in a way that maintains the convenience but reduces the
| accident likeliness. Holding a modifier key or adding leader keys
| actually does seem like I'd go a long way in reducing accidents
| with minimal hit to effectiveness
| michaelbuckbee wrote:
| I've used the Vimium chromium extension for years and it has a
| keypress to activate the search links and you can also disable
| it per domain.
| fleaaa wrote:
| With Vimium, you can toggle the type to navigate mode so that
| it doesn't invoke unwarranted shortcut
| sourcepluck wrote:
| Someone was triggered by the Nyxt post getting so much
| attention... =D
|
| I like Qutebrowser very much, though. Used it for a good spell
| and was very happy. I'd some bug I couldn't fix which was driving
| everything really bonkers, but I honestly did not investigate it
| that hard, I'd been using it for a while at that stage (over a
| year, I'd guess, anyway) and was ready to move on and try
| something different, so I solved that bug the old fashioned way.
|
| Nyxt scratches the same itch now, but moreso, and it has Common
| Lisp behind it, which is much more interesting [to me
| _personally_!] than Python.
| einpoklum wrote:
| Must be the cutting-edge-pun-not-intended browser compeition
| day...
| fleaaa wrote:
| Vimium does the same but it's just an extension so you can keep
| the goodies without switching the browser
| w4rh4wk5 wrote:
| The README mentions some ad-blocker integration. Is there an
| element zapper (click on element on the page to remove it
| temporarily)?
| The-Compiler wrote:
| The devtools let you do that FWIW.
| bheadmaster wrote:
| Florian Bruhin (AKA the-compiler, the author of qutebrowser) is
| one of the kindest and most dedicated open-source maintainers
| I've ever had the pleasure to interact with.
|
| I've used qutebrowser extensively in the past, and reported a few
| bugs, each of which has been met with interest and engagement.
| Some of them even uncovered bugs in the upstream software (e.g.
| QtWebEngine) which were reported there.
|
| I eventually stopped using it when YouTube ads became too
| invasive, and went back to Firefox + Vimium + uBlockOrigin. I
| sometimes miss the programmibility of qutebrowser, but Vimium at
| least gives me the basic Vim-like browsing features.
| The-Compiler wrote:
| <3
| einpoklum wrote:
| 1. It's QtWebEngine + Python tying the chrome together.
|
| 2. I wonder... how good is its Right-to-Left support?
| The-Compiler wrote:
| RTL support should be as good as Chromium's for web contents
| (as QtWebEngine is based on Chromium), and as good as Qt's for
| the UI. Admittedly I never tested, but if you notice something
| in the UI that doesn't look right, I'd be happy to have a look
| and see if there's something that can be improved there.
| metta2uall wrote:
| I'd love to use this but a key problem seems to be that they
| don't get updated as soon as a security fix is released, which
| for browser engines is quite often...
| The-Compiler wrote:
| Note that on Linux, the browser engine (QtWebEngine) is
| installed/updated separately from qutebrowser. They have a new
| feature release (updating to a new Chromium baseline) every 6
| months, with patch releases backporting security fixes every
| 1-2 months. Not optimal, but some Linux distributions also
| backport security fixes as soon as they happen, which is much
| more often: https://codereview.qt-
| project.org/q/project:qt/qtwebengine-c...
|
| Then there is the issue of "stable" Linux distributions (mostly
| Debian/Ubuntu) which never get those updates to you
| unfortunately, and don't seem to care about those being
| security-relevant either. Not much either qutebrowser and Qt
| can do about that sadly, but you can install Qt from somewhere
| else, e.g. from the PyQt binary builds if you don't mind losing
| proprietary codec support:
| https://qutebrowser.org/doc/install.html#tox
|
| As soon as a new Qt/PyQt is out, there is usually also a new
| qutebrowser release bundling it for Windows/macOS releases.
| krobelus wrote:
| Amazing project, very useful
| sunshine-o wrote:
| Qutebrowser is a prime example of how to fix the user experience
| of a somehow not optimal software (the web browser).
|
| Of course you need to understand vi as a prerequisite, a few
| hours to configure it and maybe a few weeks to really get you use
| to it.
|
| But damn the benefits after are enormous.
|
| Congratulations to the developers !
| The-Compiler wrote:
| Thanks for the nice words! :)
___________________________________________________________________
(page generated 2024-12-09 23:02 UTC)