|
the cutting edge of web browsing, netscape navigator
|
#
?
Mar 27, 2024 18:51
|
|
|
|
| # ? Apr 28, 2024 23:26 |
|
|
Cybernetic Vermin posted:ive never looked into it, but presumably uwp and winui have the full application lifecycle infrastructure for actually doing power saving in a principled way (all that worked fine in wp, and for all their failures microsoft will not usually throw that kind of thing out) i believe they do, but i don't develop windows apps so i'm not certain how. either way edge isn't the only "modern" app that's asked me about power saving settings
|
|
#
?
Mar 27, 2024 18:52
|
|
|
dioxazine posted:the cutting edge of web browsing, netscape navigator
|
|
#
?
Mar 27, 2024 18:53
|
|
|
The_Franz posted:firefox and chrome do this on windows by hooking into the windows of all other applications so they can build a grid of windows and figure out if their window is currently occluded by others i would bet this is because they're classic win32 apps and probably will be for quite a while. when they were first developed wddm wasn't even a thing universally (in chrome's case, firefox is older, obviously), let alone any of the newer app frameworks although i suppose chrome could pick up microsoft's changes to edge for the windows port, idk
|
|
#
?
Mar 27, 2024 18:54
|
|
|
pretty sure edge is very win32 beneath a very thin skin. but also they are all major application frameworks in their own right, managing major applications themselves, and the things offered by the os are probably not very relevant at that scale as long as they provide enough info and don't restrict them unduly
|
|
#
?
Mar 27, 2024 18:57
|
|
|
mystes posted:I think early mozilla milestone releases had the most sharp edges really they also had that sweet blueprint looking theme
|
|
#
?
Mar 27, 2024 18:58
|
|
|
Cybernetic Vermin posted:pretty sure edge is very win32 beneath a very thin skin. yeah idk, i've never looked at the source for edge. it definitely has some "modern" features, but at the same time largely uses its own libraries for most things. i always figured that was because of its chromium lineage but maybe that's also what's blocking them from going totally uwp or whatever it's called now i also never quite knew why they didn't keep the old edge's shell (which was definitely uwp) while just swapping out the rendering engine. i can't imagine there are many people using edge cross-platform, so idk how ms benefits from edge being a heavily yet barely modified chromium
|
|
#
?
Mar 27, 2024 19:00
|
|
|
Beeftweeter posted:they also had that sweet blueprint looking theme this was the nice part
|
|
#
?
Mar 27, 2024 19:05
|
|
|
Beeftweeter posted:i also never quite knew why they didn't keep the old edge's shell (which was definitely uwp) while just swapping out the rendering engine. i can't imagine there are many people using edge cross-platform, so idk how ms benefits from edge being a heavily yet barely modified chromium true, though i do use edge on linux, so i am thankful it is a good "port"
|
|
#
?
Mar 27, 2024 19:14
|
|
|
dioxazine posted:this was the nice part there was one afterwards i liked a lot too. it was pretty similar in iconography but had more gradients and bevels for a subtle 3d-ish look
|
|
#
?
Mar 27, 2024 19:14
|
|
|
Cybernetic Vermin posted:true, though i do use edge on linux, so i am thankful it is a good "port" it does seem preferable to literal google chrome, but maybe not chromium or some other fork that rips out the tracking and advertising bullshit. but ms is almost as guilty as google there, and is in some cases actually worse, so maybe there's some edge port like that now too? idk, i'm just having a hard time imagining a use case for it. on windows, there's some actual benefit to using edge: it's optimized for it, and it does a good job of hooking into or otherwise emulating windows' behavior (since it's still just chromium underneath) on linux or macos you might as well be using straight up chromium i think. unless i guess you need entra id integration or something? or you just really, really like copilot? 
|
|
#
?
Mar 27, 2024 19:21
|
|
|
im in some microsoft ecosystems, and partially on windows. when i first started the authenticator-connected autofill was an edge feature. now the extension is on any chromium. but now i use some other features (e.g. collections) a bit, plus i use "edge" on ios, where getting decent integrations is a bit touchier. also nothing about edge on linux in and off itself has given me any reason to switch, has been entirely problem-free as such.
|
|
#
?
Mar 27, 2024 19:28
|
|
|
Cybernetic Vermin posted:im in some microsoft ecosystems, and partially on windows. when i first started the authenticator-connected autofill was an edge feature. now the extension is on any chromium. but now i use some other features (e.g. collections) a bit, plus i use "edge" on ios, where getting decent integrations is a bit touchier. fair enough, i jump between oses pretty frequently too so i get where you're coming from there. i usually don't bother with anything fancy like collections though, but i do have icloud bookmark/password sync (which also exists as a chromium plugin now) set up to work with/supplement edge autofill, which i also have on ios as an alternate to icloud passwords, so they update each other depending on where i'm adding a new account/bookmark worth noting having a firefox account and using lockwise (or whatever they rebranded it to, i think it's just integrated into the main firefox app now) accomplishes much of the same thing, although there's only a bookmark sync plugin for firefox, not passwords. but you can work around that by having icloud passwords update firefox's also on ios and vice versa i use either with safari on ios though. edge's interface on ios is a godawful terrible mess and firefox's is kinda too simplified. safari kinda hits the sweet spot, although i really wish icab mobile had similar sync functionality since you can make it nearly identical to safari while having the more advanced functionality hidden away
|
|
#
?
Mar 27, 2024 19:45
|
|
|
so if i'm understanding this correctly phoronix went and wrote an article "SDL3 Will Keep Wayland Default At Least for the Time Being" based on this comment on the PRhttps://github.com/libsdl-org/SDL/pull/9345 posted:Thanks for the feedback everyone! then two hours later the SDL project lead came back with a nearly complete reversal: quote:Since the performance issues motivating this PR are resolved by the combination of fifo-v1 and commit-timing-v1, let's check for those protocols before using Wayland by default. i say "nearly complete reversal" because apparently those two protocols don't actually exist? like there are two open merge requests against the wayland-protocols repo that are tagged Needs acks, Needs implementations, Needs review: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/248 so i would assume that no compositors actually implement those protocols? certainly no released versions, anyway shackleford fucked around with this message at 20:23 on Mar 27, 2024 |
|
#
?
Mar 27, 2024 20:19
|
|
|
yeah, i think the correct conclusion is "sdl is staying xwayland default" and phoronix was a bit too hasty reading sam's a bit too hasty summary closing out the fruitless conversation
|
|
#
?
Mar 27, 2024 20:51
|
|
|
Compare the names in the discussions on those MRs. The simple truth is that there's usually overlap between those projects and they may implement things in anticipation of their inclusion in their dependencies, because people work on both or talk to each other.
|
|
#
?
Mar 27, 2024 20:52
|
|
|
Cybernetic Vermin posted:yeah, i think the correct conclusion is "sdl is staying xwayland default" and phoronix was a bit too hasty reading sam's a bit too hasty summary closing out the fruitless conversation no, it will use wayland by default, but only if the implementation supports the necessary protocols. basically it sidesteps the current issue while avoiding any future drama around changing the defaults
|
|
#
?
Mar 27, 2024 21:52
|
|
|
which versions of which compositors do i need to install to get it to use wayland by default? if there are no such released versions, which development branches of which compositors can be used to test this functionality? like afaict (i could be wrong) the code in that most recent PR (https://github.com/libsdl-org/SDL/pull/9383) is completely untested and untestable right now, and the de facto default is xwayland
|
|
#
?
Mar 27, 2024 21:56
|
|
|
 i just use the little dropdown on SDDM where it says "Plasma (Wayland)" vs the one that says "Plasma (X11)"for real though i didn't even know sdl3 existed lol. sounds like it's going to use x11 unless you set SDL_VIDEO_DRIVER to whatever it expects for wayland (which would ideally just be "wayland", but who knows, i've seen way crazier envs)
|
|
#
?
Mar 27, 2024 22:00
|
|
|
SDL 3 doesn't exist yet. There's a huge wishlist of things people want from SDL 3 so it's going to take a long while.
|
|
#
?
Mar 27, 2024 22:07
|
|
|
seems like the main branch calls itself 3? the current release is 2.3.x, which has its own i mean, i get that it's nowhere near finished, but i didn't know they'd even started work on it
|
|
#
?
Mar 27, 2024 22:12
|
|
|
yeah they released the first preview release "3.1.0" the other day. i think they're trying to get all the backwards incompatible ABI/API breaks done soon
|
|
#
?
Mar 27, 2024 22:16
|
|
|
hmm backwards incompatible eh a lot of poo poo uses sdl2, so hopefully you can have 3 installed alongside 2 like you can 1
|
|
#
?
Mar 27, 2024 22:21
|
|
|
yeah they're different SONAMEs, like libSDL2-2.0.so.0 vs libSDL3.so.0 or whatever. they're trying to lock down the breaks going into libSDL3.so.0 relatedly, there is a compatibility layer https://github.com/libsdl-org/sdl2-compat
|
|
#
?
Mar 27, 2024 22:28
|
|
|
shackleford posted:yeah they're different SONAMEs, like libSDL2-2.0.so.0 vs libSDL3.so.0 or whatever. they're trying to lock down the breaks going into libSDL3.so.0 sdl2-compat works really well. the ue5 editor actually runs better with sdl3 via sdl2-compat, because sdl3 has proper popup window support for menus and tooltips
|
|
#
?
Mar 27, 2024 22:54
|
|
|
shackleford posted:yeah they're different SONAMEs, like libSDL2-2.0.so.0 vs libSDL3.so.0 or whatever. they're trying to lock down the breaks going into libSDL3.so.0 that’s pretty stupid, it should be libSDL-2.0.0.so and libSDL-3.1.0.so and so on, and everything that worked when built against the former should work perfectly and transparently when run against the latter newer versions should check the linked-against version if necessary to put in place compatibility hacks if they really need to change API behavior between versions really this is like table stakes poo poo for implementing and maintaining libraries, what is it about Linux that breaks people’s brains such that think this kind of idiocy is acceptable? you don’t break end user software that obeys the API contract, it doesn’t matter whether your code runs in kernel or user space, you just don’t loving do it
|
|
#
?
Mar 28, 2024 11:32
|
|
|
… the whole point of giving it a different name is that it guarantees that they cannot possibly break any existing sdl2 software even by accident, why are you so angry about the way they are accomplishing this
|
|
#
?
Mar 28, 2024 11:46
|
|
|
Soricidus posted:… the whole point of giving it a different name is that it guarantees that they cannot possibly break any existing sdl2 software even by accident, why are you so angry about the way they are accomplishing this
|
|
#
?
Mar 28, 2024 11:48
|
|
|
users don’t deserve a stable API
|
|
#
?
Mar 28, 2024 15:24
|
|
|
Soricidus posted:… the whole point of giving it a different name is that it guarantees that they cannot possibly break any existing sdl2 software even by accident, why are you so angry about the way they are accomplishing this i might be misunderstanding but i think the objection is to the compatibility layer not just being the default?
|
|
#
?
Mar 28, 2024 15:29
|
|
|
libmap is pretty neat
|
|
#
?
Mar 28, 2024 18:06
|
|
|
eschaton posted:that’s pretty stupid, it should be libSDL-2.0.0.so and libSDL-3.1.0.so and so on, and everything that worked when built against the former should work perfectly and transparently when run against the latter nah the proper GNU/Linux way to accomplish what you're talking about is never bumping the SONAME and adding fine grained symbol versioning information to newly added symbols and then not breaking the API exposed in the headers. this is how glibc works and why you can compile and link something against an old rear end libc.so.6 and it will run against a modern libc.so.6 if anything the SDL approach here seems kinda windows brained
|
|
#
?
Mar 28, 2024 20:35
|
|
|
well, sdl is a game library, you have to do windows brained things when interacting with game devs otherwise they will short circuit
|
|
#
?
Mar 28, 2024 21:42
|
|
|
shackleford posted:nah the proper GNU/Linux way to accomplish what you're talking about is never bumping the SONAME and adding fine grained symbol versioning information to newly added symbols and then not breaking the API exposed in the headers. this is how glibc works and why you can compile and link something against an old rear end libc.so.6 and it will run against a modern libc.so.6 except that your old thing also links against libncurses5 and your new linux has libncurses6 and it’s literally impossible to install libncurses5 alongside it because they require their data files to be in the same location but use different incompatible binary data formats (and nothing even uses the extra precision in the version 6 files, they increased some field sizes and broke compatibility entirely pointlessly because all the values anyone has ever wanted or will ever want can fit perfectly well in the old fields) … I love linux
|
|
#
?
Mar 28, 2024 22:05
|
|
|
yeah it doesn't always work well, especially if you're compiling something that expects a certain minor version number like editing the so manually can sometimes work in a pinch but that's really not a great idea
|
|
#
?
Mar 28, 2024 22:27
|
|
|
Soricidus posted:except that your old thing also links against libncurses5 and your new linux has libncurses6 and it’s literally impossible to install libncurses5 alongside it because they require their data files to be in the same location but use different incompatible binary data formats (and nothing even uses the extra precision in the version 6 files, they increased some field sizes and broke compatibility entirely pointlessly because all the values anyone has ever wanted or will ever want can fit perfectly well in the old fields) this bullshit is what they claim is “fixed” by containers shared libraries my rear end. just statically link everything dude. fuckitall.
|
|
#
?
Mar 28, 2024 23:46
|
|
|
Soricidus posted:except that your old thing also links against libncurses5 and your new linux has libncurses6 and it’s literally impossible to install libncurses5 alongside it because they require their data files to be in the same location but use different incompatible binary data formats (and nothing even uses the extra precision in the version 6 files, they increased some field sizes and broke compatibility entirely pointlessly because all the values anyone has ever wanted or will ever want can fit perfectly well in the old fields) complain to your linux distro. mine provides working, co-installable libncurses.so.5 and libncurses.so.6 SONAMEs
|
|
#
?
Mar 28, 2024 23:47
|
|
|
fresh_cheese posted:shared libraries my rear end. just statically link everything dude. fuckitall. this unironically
|
|
#
?
Mar 28, 2024 23:48
|
|
|
works great until your library needs to load library data off the filesystem
|
|
#
?
Mar 29, 2024 00:01
|
|
|
|
| # ? Apr 28, 2024 23:26 |
|
|
fresh_cheese posted:shared libraries my rear end. just statically link everything dude. fuckitall.
|
|
#
?
Mar 29, 2024 00:03
|
|