Quoting: CioranixGnome needs stable extensions, maintained by people that know what they are doing. This was the way to go. Instead we will now have a future with more unstable extensions, broken icon-sets/gtk-themes, and more work for package maintainers as well.

'Hyperextensibility' (as the neovim folks call it) with easy to use, well documented, stable apis, is really what people building on GNOME/GTK should strive for, not 'customizability'.

GNOME/GTK already has the technologies -- the GObject model, with bindings for every major language, which would allow end users to extend apps in whatever way they like, provided that the base version exposes a good range of functions, events, signals, whatever. It then becomes a moot issue as to whether Nautilus has an info bar or split panes in the base version -- someone with modest Python skills could provide that as an extension to the community easily, IF Nautilus were to expose more than bare bones 'MenuProvider' & 'ColumnProvider' objects for the extension to 'talk to'.

I strongly believe that what hinders GNOME developers from exposing more of the base apps like this, & document them, is the lack of manpower. *That* is where the resources of a company like System76 can be helpful.

View this comment - View article - View full comments

The blog post and the repo aren't terribly informative as to the scope of this project, though. I thought for a moment that this would be like Elementary OS, building on GTK (even contributing to Vala development), but so far it looks like a collection of GNOME extensions in js.

I'd really love for them to work on enhancing the dbus interfaces of existing applications, making them easier to use, & improving -- or filling in the missing -- documentation. That would open up a new world of easy to write/easy to use custom utilities, scripting possibilities. OS X did (does it still? I don't know) this with the shared object api that the user could easily 'talk to'/script with Applescript or even Automator -- an GUI tool that allowed building simple utilities by dragging blocks of functions into an input-output queue.

We seem to have a fixation on customizing keystrokes & window selection mechanisms in the Linux world; but there are further possibilities to be explored in UI design. We already have technologies like dbus messaging that need proper documentation, & fleshed out interfaces.

View this comment - View article - View full comments

The passthrough bit is interesting. I wonder what led to the change in policy. It might actually be worth trying out, now that it's less of a flaky hack. Last time I set it up I wasn't impressed at all with the results.

View this comment - View article - View full comments

Quoting: ArehandoroI had it installed, along with few more, and on 40 they all don't work :(

There have been important changes to the API; so I expect a lot of breakage:
https://blogs.gnome.org/shell-dev/ [External Link]

& porting extensions needs quite a bit of work:
https://gjs.guide/extensions/upgrading/gnome-shell-40.html [External Link]

View this comment - View article - View full comments

Quoting: GuestThey all copy from each other what they think their users like. Besides, which DE is actually original? The only ones that I think are truly different in my experience are the tiling window managers but even those aren't original either.

I would've liked to use Jeff Raskin's original plan for the Mac (before Steve Jobs fired him, & canned his design); or the smalltalk system — though I'd be perfectly content if the current paradigm we have just *survives* the flat, poor contrast, mobile-first design fads.

By the way Mac OS has really jumped the shark in the UI department with the last round of updates. This guy gives good examples: http://morrick.me/archives/9150 [External Link] (Be warned though; this is an Apple fan; so there's plenty of BS as well.) At least Gnome doesn't *hide* buttons & tabs into a grey-on-white fog when you're not hovering over them.

View this comment - View article - View full comments

Quoting: 3zekielA secondary issue is that it is the supreme bloat since you really pack a whole lot of things in your app, and its corrolary: you can't update any part yourself - is it monolithic -, whereas for flatpak, you could force a newer runtime for the basics at least, or overload an installed flatpak with new features/libs if you want.

As you say, it is not a complete blocker either, and it does have some cases where it can be useful for distribution by stores like gog as an example. RPCS3 which does have a flatpak is not the best example though :)

I might be misunderstanding your point here, but AppImage currently does allow incremental updates: https://docs.appimage.org/packaging-guide/optional/updates.html [External Link]

I've been using the zsync method to update the neovim nightly appimage from github; it works just fine — that is the developer (without going through any intermediary) incrementally updates the nightly image on github every day, and the delta is all I have to download.

View this comment - View article - View full comments

Looks really interesting; great that it has a demo too.

Quoting: no_information_hereSeeing them bending gravity and light in the trailer was cool. Wishlisted!
(I do miss Portal and Talos.)

Have you played 'DeadCore'? https://store.steampowered.com/app/284460/DeadCore/ [External Link] it's like a cross between puzzler & speed runner -- and *very* difficult. But it does scratch the portal-like itch a *little* bit.

Also, they're not Linux native, but you might want to check out the 'Qube' games.

View this comment - View article - View full comments

Quoting: JuliusFinally!

Edit: arg, seems like x86_64 only. Why Valve? Why? We were able to run a normal Steam Linux client on x86 before :( What is really missing is an Arm64 build of the steam-link :(

Does the Raspberry Pi 4 run arm64 binaries? Maybe they'll release an update for the Rpi version (I mean this: https://support.steampowered.com/kb_article.php?ref=6153-IFGH-6589 [External Link] ) eventually.

View this comment - View article - View full comments

Quoting: dpanter

Quoting: wvstolzingIt requires libglfw3 3.3 min.; while Debian (which I'm currently using, after random nvidia-related f*ckups with Arch that I got fed up with) still has 3.2.1 as of now.

Or... grab libglfw3 3.3.2-1 from testing. 3.3 has been available in Debian repos since July 2019. :)

I eventually built libglfw3 from source; but the build for 'RE' still fails.

... I also confess, that I'm not confident enough to mix stable & non-stable repos on Debian. I use backports & flatpak & appimages & source builds when I need something new.

View this comment - View article - View full comments

Quoting: LinuxwarperNow add raytracing and it will be even better.

Are they planning to do that? I've seen some pretty nice experiments on youtube, using a different reverse-engineered engine or mod or hack (can't really tell what it is):
https://www.youtube.com/watch?v=fPnw78wJYgc [External Link]
Adds a pretty nice mood to GTA3, I think. The VC examples aren't as good.

This is the 'engine' in question. It's (partly?) built on Vulkan, so a Linux version could be a possibility:
https://github.com/petrgeorgievsky/gtaRenderHook [External Link]

View this comment - View article - View full comments