• 0 Posts
  • 251 Comments
Joined 2 years ago
cake
Cake day: September 2nd, 2023

help-circle


  • My comment explicitly avoids the “standard” problem.

    A user could have many "theming system"s installed at once, while only having 1 DE. The user ideally would configure only one, and some program should try to translate that system into the other ones.

    Then each app will fetch the list of theming systems the user has installed, and choose whichever the app prefers. And if there’s no match, fall back to a default hard coded theme.



  • I see you ignored my entire comment.

    I don’t know what is more explicit about expect. Unwrap is as explicit as it gets without directly calling panic!, it’s only 1 abstraction level away. It’s literally the same as expect, but without a string argument. It’s probably top 10 functions most commonly used in rust, every rust programmer knows what unwrap does.

    Any code reviewer should be able to see that unwrap and flag it as a potential issue. It’s not a weird function with an obscure panic side effect. It can only do 2 things: panic or not panic, it can be implemented in a single line. 3 lines if the panic! Is on a different line to the if statement.


  • This can also be a side product for code blocks being expressions instead of statements.

    In rust for example they are, so it’s not rare to see functions like:

    fn add_one(x: i32) -> i32 {
        x+1
    }
    

    This lets you do amazing things like:

    let x = if y < 0.0 {
        0.0
    } else {
        y
    }
    

    which is the same as x = y < 0.0 ? 0.0 : y

    But is much better for more complex logic. So you can forget about chaining 3-4 ternary operations in a single line.


  • An unhanded error will always result on a panic (or a halt I guess). You cannot continue the execution of the program without handling an error (remember, just ignoring it is a form of handling). You either handle the error and continue execution, or you don’t and stop execution.

    A panic is very far from a segfault. In apparent result, it is the same. However, a panic is a controlled stopping of the program’s execution. A segfault is a forced execution stop by the OS.

    But the OS can only know that it has to segfault if a program accesses memory outside its control.

    If the program accesses memory that it’s under it’s control, but is outside bounds, then the program will not stop the execution, and this is way worse.

    EDIT: As you said, it’s also an important difference that a panic will just stop the thread, not the entire process.





  • I’ve got all that. I just needed to convert a string of characters into a list of glyph IDs.

    For context, I’m doing a code editor.

    I don’t use harfbuzz for shaping or whatever, since I planned on rendering single lines of mono spaced text. I can do everything except string->glyphs conversion.

    Just trying to implement basic features such as ligatures is incredibly hard, since there’s almost no documentation. Therefore you can’t make assumptions that are necessary to take shortcuts and make optimizations. I don’t know if harfbuzz uses a source of documentation that I haven’t been able to find, or maybe they are just way smarter than me, or if fonts are made in a way that they work with harfbuzz instead of the other way around.

    As someone trying to have as little dependencies as possible, it is a struggle. But at the same time, harfbuzz saved me soo much time.

    EDIT: I don’t do my own glyph rasterization, but that’s because I haven’t gotten to it yet, so I do use a library. I don’t know if it’s going to be harder than string->glyphs, but I doubt so.


  • I cannot comprehend what the fuck harfbuzz does.

    I tried to implement my own because “I don’t need all the features, I’m gonna render self-to-right western text with very few font features”. But holly fuck, the font format documentation is barely non-existent. And when I tried my naive solution it was like 10000x (or more) slower than harfbuzz.





  • I don’t understand why any user would have to care or even know what GUI toolkit an app uses.

    I don’t know why the burden is put on the user/DE. You shouldn’t have to care about what GUI toolkit your DE uses either.

    DE and themes should be decoupled from eachother. So the user can install whatever “theming system” they want, and GUI toolkits should aim to support as many theming systems as practical.

    GUI toolkits are implementation details, the user doesn’t care about implementation, it cares about what it sees. And what it sees is the colors and icons.