I hardcoded size and position values in Sway to hide it outside the screen.

Here they are for 1366x768:

for_window [app_id="dev.zed.Zed"] floating enable, \
                                    resize set width 1387 px, \
                                    resize set height 830 px, \
                                    move position -15 -75


bindsym $mod+2 workspace number 2, \
    for_window [app_id="dev.zed.Zed"] floating enable, \
                                        resize set width 1387 px, \
                                        resize set height 810 px, \
                                        move position -8 -60

This won't work unless I keep Zed in workspace 2 though.

If I don't re-run the command when switching workspaces Zed changes position and breaks my hack. There should be a better solution to the workspace problem.

Edit: I know I input different values in both cases, but it doesn't work otherwise.

I shaved off 10 MiB from my binary in 2 hours!

I made a program using Macroquad, then I built it in release mode, the binary was 63 MiB in size.

So I used cargo vendor to have a better look at Macroquad and one of its dependencies, glam.

I then started to delete code, like, lots and lots of code(about 30_000 lines of code); none of it affected my main project, some of it became 'dead_code' just by removing the pub keyword.

The result is that my project was unaffected and the binary went down to 52 MiB.

Is there a way to automate removal of unneeded elements from dependencies? This is potentially huge.

EDIT: I FIGURED IT OUT!!!

My mistake was measuring the size of "target/release", I discovered that that folder contains many "unnecessary" files, like "deps", which greatly bloat the folder'r size, the actual size of my binary is 864K.

I am so relieved.

How safe it is to upgrade to Pop!_OS 24.04 by manually editing /etc/apt/sources.list (or whatever it was).

I tried doing it and running sudo apt update, and nothing suspicious seemed to appear. I used the Ubuntu 24.04 repos.

It is worth nothing that I have ran sudo apt remove with the --allow-remove-essential flag; I did it long ago to remove some "bloat".

I want to upgrade; 22.04 is so old Debian stable is more up-to-date. There are also bugs with Sway and Mangohud that I am interested in getting rid of.

I am uninterested in the Rust desktop.

It might be lack of sleep, but I can't figure this out.

I have a Label, and I want its text to be red when it represents an error, and I want it be green when it represent "good to go".

I found search result for C and maybe a solution for Python, but nothing for Rust.

I tried manually setting the css-classes property and running queue_draw(); it didn't work.

I can have a gtk::Box or a Frame that I place where the Label should go, then declare two Labels, and use set_child() to switch between them, but that seems like an ugly solution.

Do you have a solution?

SOLVED:

I have to add a "." before declaring a CSS "thing" for it to be considered a class.

Ex:

.overlay {
        background: rgba(60, 60, 60, 1);
        font-size: 25px;
}

instead of:

overlay {
        background: rgba(60, 60, 60, 1);
        font-size: 25px;)
}

Just use label.add_css_class(), label.remove_css_class() or label.set_css_classes() and make sure to properly load your CSS style sheets,

Source: the comment of [email protected]

I was using Iced as a dependency, but wanted to tweak its source code for some reason, so I jumped into the folder where cargo downloads dependencies, and went into iced_wgpu 13.5 (I think that's the version).

I could make a change, then run

cargo clean -p iced_wgpu && cargo check

in my other project for instant feedback, yet it took rust_analyzer at least 5 whole minutes to stop hallucinating.

Can I disable some functionality of rust_analyzer? I only use it for jump-to-definition, linting and syntax highlighting; I don't even use autocomplete.

Setup:

• Desktop that thermally throttles only when both the IGPU and the CPU are under full load, and is cool otherwise.

• CPU: Intel I5-7500

• RAM: 8 GiB DDR-4

• Editor: NVIM v0.11.0-dev | Build type: RelWithDebInfo | LuaJIT 2.1.0-beta3 (I had the same issue with other versions as well).

TLDR

What can I disable in rust_analyzer to boost performance while maintaining jump-to-definition, linting and syntax-highlighting, or what can I do to boost rust_analyzer for big projects in general?

Another crazy idea I share with this website.

I was developing a game and an engine in Rust, so I was reading many articles, most of which criticize the 'borrow checker'.

I know that Rust is a big agenda language, and the extreme 'borrow checker' shows that, but if it weren't for the checker, Rust would be a straight-up better C++ for Game development, so I thought: "Why not just use unsafe?", but the truth is: unsafe is not ergonomic, and so is Refcell<T> so after thinking for a bit, I came up with this pattern:

let mut enemies = if cfg!(debug_assertions) {
    // We use `expect()` in debug mode as a layer of safety in order
    // to detect any possibility of undefined bahavior.
    enemies.expect("*message*");
    } else {
    // SAFETY: The `if` statement (if self.body.overlaps...) must
    // run only once, and it is the only thing that can make
    // `self.enemies == None`.
    unsafe { enemies.unwrap_unchecked() }
};

You can also use the same pattern to create a RefCell<T> clone that only does its checks in 'debug' mode, but I didn't test that; it's too much of an investment until I get feedback for the idea.

This has several benefits:

1 - No performance drawbacks, the compiler optimizes away the if statement if opt-level is 1 or more. (source: Compiler Explorer)

2 - It's as safe as expect() for all practical use cases, since you'll run the game in debug mode 1000s of times, and you'll know it doesn't produce Undefined Behavior If it doesn't crash.

You can also wrap it in a "safe" API for convenience:

// The 'U' stands for 'unsafe'.
pub trait UnwrapUExt {
    type Target;

    fn unwrap_u(self) -> Self::Target;
}

impl<T> UnwrapUExt for Option<T> {
    type Target = T;

    fn unwrap_u(self) -> Self::Target {
        if cfg!(debug_assertions) {
            self.unwrap()
        } else {
            unsafe { self.unwrap_unchecked() }
        }
    }
}

I imagine you can do many cool things with these probably-safe APIs, an example of which is macroquad's possibly unsound usage of get_context() to acquire a static mut variable.

Game development is a risky business, and while borrow-checking by default is nice, just like immutability-by-default, we shouldn't feel bad about disabling it, as forcing it upon ourselves is like forcing immutability, just like Haskell does, and while it has 100% side-effect safety, you don't use much software that's written in Haskell, do you?

Conclusion: we shouldn't fear unsafe even when it's probably unsafe, and we must remember that we're programming a computer, a machine built upon chaotic mutable state, and that our languages are but an abstraction around assembly.

I know the title looks insane, but hear me out.

I wanted to make a game, specifically an isometric 2.5D RPG game, nothing that fancy.

So I decided to write it in Rust because I... like Enums, or something, and I had already finished the concurrency chapter, so I should be able to hang on.

Bevy seemed like the most complete engine out there, if overkill for my use case, but it's presumably so modular I could de-bloat it adequately, But...

Someone I know has a laptop; it is old.

It is not super old, a Toshiba Portege R700 with a locked BIOS which took me 3 days to trick its Windows 10 boot loader into booting Debian, and accidentally, yet irresponsibly, broke Windows and installed Grub.

There is no reason the thing shouldn't be able to run my hypothetical game. I've personally seen it LANning Sven Co-Op (Half-Life Co-Op) not long ago; the beast could maintain 60FPS for a solid few minutes, before overheating and dropping to 5, but it should hold on better now that I installed GNU/Linux.

So I, just to make sure, ran the command that exposes the OpenGL version used by Mesa, and... Open GL (ES?) 1.5? I surely, need a plan.

I noticed this issue with many indies. Many would-run-on-a-2005-thinkpad games sacrifice this untapped market for features they never use, or worse, go against the artistic vision.

So, since Bevy is modular, can I, a humble would-be-intern, write a rendering backend for the 2003 specification, but not before learning what a rendering backend is?

Or can I, a seasoned searcher, find a premade solution solution for Bevy or any other Rust engine, made to use the 2003 spec, or even the 1992 1.0 spec?

Or would it be worthwhile, to construct an engine of mine?

Edit: Or can I, a man of determination, write an FFI for an existing C solution?

I have written a calculator in Rust and libcosmic, the design is copied from gnome-calculator; I discovered 2 things:

1. I don't like working on UIs.
2. I have no idea how to transform

cosmic::widget::button::Builder

to

cosmic::widget::Button;

this code would be so much cleaner if I could return a button::standard() from a function.

The source code.

I have a huge library of game EXEs on my computer, but they run at a 4:3 aspect ratio as they're old, Proton/Proton-GE/WINE-GE keep the aspect ratio and place black bars left and right, which is desireble, unlike wine who stocks them to the left side of the screen.