• 11 Posts
  • 231 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle

  • BartyDeCanter@lemmy.sdf.orgtolinuxmemes@lemmy.worldGUIs
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    13 hours ago

    So true. I mostly live in the embedded world but have had to write GUIs from time to time, mostly to connect and send commands to some sort of embedded device.

    I always start with a cli version for testing and then write the GUI. A quick wrapper around the comms library and I’m done.

    But there are so many annoying fiddly little details in the GUI to deal with that it usually takes as long just to write the GUI as it does the entire rest of the code. Layout, menus, tooltips, icon choices, dealing with screen sizes, DPI, resizing windows, responsive data, etc.

    Edit: A simple example that I’ve dealt with many times is reading and writing config data. For the CLI version it’s typically two commands:

    ‘tool read_cfg’ reads from the device and prints the config to stout

    ‘tool write_cfg’ reads a config from stdin and sends to the device.

    Add a ‘-f’ option to use a file instead of stout for people that don’t remember how to use redirects. Add a couple of documentation sentences to the help command. If there are any issues, print them to stderr and bail. If the user wants to edit the config they can use whatever $EDITOR they prefer.

    The same functionality in a GUI means that you have to first implement an editor for values. In my case that was generally a bunch of nested key/value pairs so I could probably find a widget that would work. And then understand how it handles being resized, gets styled, uses tooltips, etc. Of course there would need to be some code to get the data into and out of that widget which would probably need massaging. Then I need to let the user know if there are local edits. And then there is the fact that the data is now in three places, on a local disc, on the device, and in the editor and I need to communicate with the user that there is a difference between loading and saving from disc vs the device. Do I give a warning that loading from once place will overwrite anything they’ve changed in the editor? How do I make the four load/save buttons have obvious icons? And how to handle errors? An annoying pop up? Partially load the data? Something else? So many little things that have to be designed, implemented, and tested.



  • The state of office desks has been continuously getting worse my entire career.

    The very first place I interviewed had small private offices with a door for everyone. They weren’t any bigger than a decent sized cubicle but were real separate rooms and most of them had exterior windows. I didn’t get that job though.

    My first desk at my first engineering job was in a cubicle with real six foot tall walls, a window with a nice view, big L desk, shelves, filing cabinets, etc.

    Then I got the same setup, but in a fabric cube. Honestly, not really a downgrade. I had that setup three times, and the only difference was how good the view was.

    Then the same but no windows.

    Then a smaller cube with a simple 6 foot desk and a single cabinet.

    Then a line of 6 foot wide desks with privacy screens on three sides.

    Then privacy screen on left and right only.

    Then no screens.

    Then four foot desks.

    My current office is four foot desks that are hotdesked for most people. But we are also completely remote if you want, so I use my nice desk that I built at home 90% of the time.



  • Yeah, the libraries are pretty great. I’m working on a kinda personal kinda professional project right now. Ideally it would support reading and writing about seven different sorta obscure file formats. For a bunch of reasons I’m writing it in rust and there is a good library for one of them, multiple half assed libraries for another, and none for any of the others. There is excellent support for all of them as a single Python library. My first step has become writing a comprehensive rust library for all of them.




  • I have been using Python as my second language alongside whatever system language I was using professionally as well as for a variety of personal projects for about 20 years. I’m quite fond of the language for the sorts of things I use it for, which is either scripting glue or doing serious math because I hate dealing with Matlab licenses.

    And you are so fucking correct it isn’t even funny. Not only is the tooling a disaster, but it seems like every few years there is a new tooling scheme that doesn’t work quite right with the old one and is a disaster in its own unique way. And

    I know people get annoyed by rust evangelists, but I started using it six months ago and god damn does cargo slap. Want to initiate new project? One command gives you the complete boilerplate. Adding a new dep? One simple command. Want to pin or unpin a version? One simple command. Want to update all the deps to latest? One simple command. Want make a release package? One simple command. Want to update all your installed packages? One simple command. Want to keep every project tied to a different version? You guessed it.

    I definitely have some issues with Rust syntax, but I want cargo to manage my life.

    Really, the a Python project needs to take a look at the Zen of Python and apply it to the tooling. And then use cargo to do it.

    Edit: And, all of those simple commands work across all platforms the same. None of this, “Everything is perfectly cross platform and is the same anywhere. Unless you’re using a Mac. Or Windows. Or the wrong Linux distro.”

    Edit x2: There is, of course, an XKCD for that.

    Edit x3: And it’s not just venv. I am constantly struggling with which pip to use on which machine. Is it pip, pip3, pipx, uv pip, conda pip?


  • Oh it absolutely is. Bringing files into Be is fine. The file type sniffer runs in the background and adds whatever metadata it can in a lightweight quick way. IIRC there are addons for specific file types like media files that add nice things like author, runtime, etc.

    Sending them out is a pain though. All the metadata is usually lost and from what I recall even emailing a file from one Be machine to another could be difficult. IIRC you could zip them and the metadata would make it, but raw files and tgz would lose it.



  • My college roommate got an install CD of the first version that ran on x86, maybe 3.0? I tried it on my computer and became an instant convert. It was so astoundingly much faster and stable than Windows was on the same hardware, had a decent free IDE, and could play MP3s without skipping while compiling, browsing the internet, and spinning a GL Teapot all at once on a Pentium 75 with 16MB of RAM. Nothing else even came close for a desktop experience. I bought a copy for myself and every version that came out.

    I’ve been daily driving Linux for a long time now, but I still look back and wonder what could have been. There are still things to this day that BeOS did better and faster in the ‘90s on single core sub GHz machines with spinning rust than Linux, MacOS or Windows can on top end modern hardware.


  • I think there are a couple of reasons. First, the Linux kernel doesn’t support resource forks at all. They aren’t part of POSIX nor do they really fit the unix file philosophy. Second, most of the cool things that BeFS enables are very end user desktop oriented, and Linux leaves that desktop environments, not the kernel. BeOS was designed as a fully integrated desktop os, not a multiuser server os. Finally, I expect that they are a security headache, as they present this whole other place that malware could be stored. Imagine an innocent looking plain text file that has an evil payload sitting in an attribute.


  • If you are nostalgic for BeOS, then the elevator pitch is, “It’s Be, only on modern hardware and more software support.”

    If you are unfamiliar with BeOS, the pitch is: “Imagine an extremely lightweight desktop is with all of the things you would expect in a modern environment with none of the legacy. In an alternative universe, BeOS would have become OSX.”

    There are so many things that Be did right from the very beginning that other OSs have adopted, but never as cleanly as Be did it.

    For example, its file system. Most people don’t really notice or care about the file system, they all have directorys and hold files, maybe with permissions. BeFS does that as well, of course, but so much more. The entire file system acts as a database, so you can easily perform fast queries on it. You can also create virtual directories that are the result of those queries.

    You want a “folder” that contains every markdown file created after 2020 between 20 and 1000kb in size? Bam, instantly done and live updated whenever something accesses it. The files aren’t actually copied there, just appear there to normal tools, almost like soft links.

    BeFS also supports a resource fork system that it calls attributes. These can also be queried using the same database like tools as the rest of the system. File typing is done this way, every file gets a MIME type attribute and there is a daemon that sniffs them when a new file is downloaded or copied over.

    Even more, this allows some crazy things like plain text files that have font, color and other formatting elements because all that is stored as an attribute.

    Or their contact information app, which stores every person as a zero length file with details as attributes. You can create a virtual folder of all your contacts that meet a certain criteria and have other applications use that folder for whatever.

    Or the email app which stores each email as a file, and adds the basic metadata like to, from, subject, read, etc as attributes. Then you can have different virtual folders based on those. This also means that the basic file system browser is the default way to view email, because it supports all the attribute viewing, queries and such you would need. Or you can do it all from the command line using either basic cli tools or some slightly specialized ones.

    Combining attributes and virtual directories makes for a fantastic media library system, all built into the os for free. Imagine a directory that contains “Every metal song I have, from 1989 to 1993, that I haven’t played in three weeks” or whatever else you want.

    Back when people used files and all applications were local first, this was probably much more exciting, but it’s still pretty cool.


  • So my oldest is almost to the point where I’m going to want them to have something for schoolwork and writing. They use a classroom Chromebook at school, but I have no idea what would make sense for them here at home. I’m an engineer who daily drives Linux, so I’m probably overthinking it. I do have an old laptop that will easily handle a lightweight distro, and as long as I don’t give them sudo it will probably be ok? Though I haven’t looked at parental controls for Linux accounts.

    What do you recommend?



  • At one point I thought like the middle guy, but I didn’t have the money to do it so my computers were made from whatever parts I could scrounge up from dumpster diving, school auctions, or whatever. I was building or upgrading my computer every six months or so with what I found.

    Once I had the money to buy basically whatever computer I wanted, I would build a high end machine and then not bother to upgrade it until I had a friend who needed one. I pass my old one on to them and the cycle repeats.

    My laptops are still random auction finds. My current one came as a pair for $40. I popped in a new SSD and battery in one and have ignored the other. I should see if Haiku supports it well enough to be worth daily driving.