Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/07/2020 in all areas

  1. Just thought the following would interest people using the UXP forks: It is the personal goal of upstream developer M.A.T. (but also backed-up by Moonchild himself) to completely debilitate all Firefox-targeting "legacy" extensions from being installable in official UXP browsers like Pale Moon/Basilisk... Already, unstable Pale Moon 29.0.0a6 official builds come without the buildconfig option "--enable-phoenix-extensions", which means already installed compatible Firefox XUL extensions will be disabled , with no option to re-enable , while "new" ones (e.g. from CAA) can no longer be installed ... One way to circumvent that artificial block is to manually edit the add-on's install.rdf file to include a Pale Moon specific <em:targetApplication> section... Or, for a more automated/user-friendly procedure, install and use JustOff's MTT: https://github.com/JustOff/moon-tester-tool/ A confrontation between M.A.T and JustOff has been brewing for some months now (on several levels), let's just say that M.A.T wasn't enthused by the CAA extension nor the recent update of the MTT one ... In a recent post: What future M.A.T. refers to is tracked in official UXP issue #1659 and work on it has already started: https://repo.palemoon.org/MoonchildProductions/UXP/commits/branch/xpiprovider-work I'm not implying, though, that official devs have any ill intent; their view on things is that they should (forcibly) migrate their users from long-deprecated, "insecure", no-longer-maintained Firefox specific legacy extensions (e.g the ones provided by CAA) - despite the fact they are currently working OK - to PM-exclusive format and extensions, forks of the original ones, with current maintainers sourced from the UXP communities (and elsewhere) ... Lofty as it may sound, the net result is yet another wave of plain user inconvenience... Should we be concerned? I'm not yet sure... I don't know what fate awaits the --enable-phoenix-extensions buildconfig flag; if the supporting code stays put, then we should be OK with regards to Fx XUL add-ons; however, in due course, upstream extensions and their repositories will move to the new format, which we'll have to somehow support too, if we are to make use of (or abuse of, as upstream claim ) ... Is supporting both formats (old: install.rdf, new: install.json) in the core browser a possibility, even? I'm no coder, so can't say myself... But, definitely, this part of the official UXP development is one our maintainer @roytam1 should keep a close eye on... Best wishes, stay safe
    2 points
  2. New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.7.win32-git-20201107-ffb32e0-uxp-19499014a-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.7.win64-git-20201107-ffb32e0-uxp-19499014a-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.7.win32-git-20201107-ffb32e0-uxp-19499014a-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.2a1.win32-git-20201107-fcd19efc9-uxp-19499014a-xpmod.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.2a1.win64-git-20201107-fcd19efc9-uxp-19499014a-xpmod.7z Official UXP changes since my last build: - Issue #1673 - Part 1: Allow tab-size to accept <length>. (49765b53a) - Issue #1673 - Part 2: Make tab-size animatable and fix typos. (7c2bcc48c) - Issue #1673 - Part 3: Bring minimum tab advance up to spec. (a2c26490b) - Issue #1673 - Part 4: Unprefix -moz-tab-size. (9ffc5e6c9) - Issue #1673 - Part 5: Fix brace style and missed -moz-tab-size reference. (d22717ff9) - Merge pull request 'Fix up -moz-tab-size and unprefix it.' (#1674) from athenian200/UXP:tab-size-length into master (9b1406f18) - [devtools] More gracefully (than a crash) handle stack capture failures. (bb4e9ad1c) - Issue #1676 - Part 1: Split MozTesting directives out of js/src/moz.build (395ef79b9) - Issue #1676 - Part 2: Split CFLAGS and CXXFLAGS directives out of js/src/moz.build (5bf19933d) - Issue #1676 - Part 3: Split DEFINES out of js/src/moz.build (0cdd39ff1) - Issue #80 - De-unify js/src (ec13658ab) - Issue #1676 - Part 4: Split builtin sources out of js/src/moz.build (24a5a7f7c) - Issue #1676 - Part 5: Split devtools sources out of js/src/moz.build (24b835f0a) - Issue #1676 - Part 6: Split ds sources out of js/src/moz.build (eedfa63a1) - Issue #1676 - Part 7: Split frontend sources out of js/src/moz.build (1396383ae) - Issue #1676 - Part 8: Fix up include for selfhosted.out.h (bc450dab4) - Issue #1676 - Part 9: Move DIRS down in js/src/moz.build (957f19d2b) - Issue #1676 - Part 10: Split gc sources out of js/src/moz.build (65eac50e2) - Issue #1676 - Part 11: Split irregexp sources out of js/src/moz.build (3d9bf5d7a) - Issue #1676 - Part 12: Split jit sources out of js/src/moz.build (95e057e73) - Issue #1676 - Part 13: Split perf sources out of js/src/moz.build (383bc182e) - Issue #1676 - Part 14: Split proxy sources out of js/src/moz.build (6f76f1cb3) - Issue #1676 - Part 15: Split threading sources out of js/src/moz.build (2f50f543a) - Issue #1676 - Part 16: Split WASM sources out of js/src/moz.build (1abc696f8) - Issue #1676 - Part 17: Put remaining source files which have debug code ifdef'd behind MOZ_DEBUG (ff355fe9a) - Issue #1676 - Part 18: Move and separate top level sources from vm sources in js/src/moz.build (59511eb8d) - Issue #1676 - Part 19: Split ctypes sources out of js/src/moz.build (cdf46e803) - Issue #1676 - Part 20: Split vtune sources out of js/src/moz.build (fd1b2dc2b) - Issue #1676 - Part 21: Use js-cxxflags.mozbuild in testing code and js shell (d2b6975eb) - Merge branch 'jsbuild-work' (2e0719919) - Issue #1677 - Part 1: Import new V8 regexp code with Mozilla's header modifications (78b3a722b) - Issue #1677 - Part 2: Add build files (19499014a) No official Basilisk changes since my last build. No official Pale-Moon changes since my last build.
    2 points
  3. Notice: These projects have no affiliation with any upstream community code sources or organizations. Please direct all support or related questions to here. "Serpent", "New Moon", "MailNews" are generic debranded names and they are subject to change in the future. Archive directory names and archive filenames will only be changed once generic debranded names are not used in the future. Latest changelog is available here as well: http://rtfreesoft.blogspot.com/search/label/browser for people who can't register here, there is another place you can create post for asking/help besides in github and blog: https://forum.eclipse.cx/viewforum.php?f=33 Serpent/UXP browser (MCP reforked 52ESR as new base), and NM28XP releases: Binaries are moved to here: (I'm lazy to edit all previous posts) https://o.rthost.win/palemoon/?sort=date&order=desc BOC and hyperbola related binaries: Binary list: https://o.rthost.win/boc-uxp/?sort=date&order=desc ------------------------------------- NewMoon 27 build: ------------------------------------- Serpent/moebius browser (deprecated by MCP, forked by me), and also 26.5 as playground : And NewMoon 26.5 and K-Meleon 74 with Goanna 2.2 (newmoon-26.5) for vanilla Win2000 build: ------------------------------------- K-Meleon browser with Goanna/Tycho engine: It has its own sub-forum in K-Meleon official forum! http://kmeleonbrowser.org/forum/list.php?19 Latest build: ------------------------------------- Firefox ESR 45 with TenFourFox fixes for IA32/SSE-only machines: ------------------------------------- K-Meleon Original cross-post is here: ------------------------------------- ArcticFox XP win32 test build: ----previous post----
    1 point
  4. Well back in 2013 I absolutely hated that os. It was weird for me at the time. Windows 8.1 improved the metro ui, added start button and for me at least improved my pc performance (especially ssd io). Telemetry can be removed, so that’s why I asked that very question. I absolutely don’t want to make anyone angry or anything, just being curious.
    1 point
  5. Connecting together the left and right channels can be bad for the sound card. If some stereo sound drives the channels to opposite phases at high volume, it can damage the built-in amplifier. It may be fine for a short while, but better not stress the old hardware by running it continuously like this. To avoid this, set the output to "mono speakers" in Control Panel > Multimedia > Playback advanced properties, and/or in the driver settings. But better just use a single channel, or add a small mixer circuit. If you hear sound when the speaker is connected between the left and right wires (instead of the ground wire), then it is bad to twist them together.
    1 point
  6. I trust more people here are familiar with the English language, am I right? https://browser.360.cn/ee/en.html (JFYI, also reported on the Vista forum a while back... )
    1 point
×
×
  • Create New...