• 16 Posts
  • 366 Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle




  • MDN (linked at the end of the article) is so much more concise. I didn’t find the broad overview in this linked article. From MDN:

    A common pattern on the web is to have <button> elements control various aspects of the page, such as opening and closing popovers or <dialog> elements, formatting text, and more.

    Historically creating these kinds of controls has required JavaScript event listeners added to the button which can then call the APIs on the element they control. The commandForElement and command properties provide a way to do this declaratively for a limited set of actions. This can be advantageous for built-in commands as the user does not have to wait for JavaScript to download and execute to make these buttons interactive.

    So built in button action commands, replacing the need for custom JavaScript for standard actions.

    The list of commands defined right now: toggle-popover, show-popover, hide-popover, close, show-modal









  • I think it’s an interesting idea, and I’d see it as fine for simple host + fetch. But as soon as you start interacting, I see it as far worse.

    A personal support email may work, but as they write by the end, ticket tracking and collaborating on a platform with a shared web interface is much superior for information sharing and but also iteration (they talk about back and forth emailing earlier).

    Self-hosting yet another platform/forge with its own account system is not viable to me either. (I’m still hoping for forgejo federation for a centralized account. Until then, GitHub seems like the best choice purely because it’s the biggest and everyone has an account and can contribute and post without account barriers.)

    The idea that it could be a hosted repo with an integrated mailing list (and potentially bug tracker) is interesting, but ultimately, almost/actually a full forge then anyway.


  • Kissaki@programming.devtoProgramming@programming.devGit without a forge
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    1
    ·
    6 days ago

    and Sourceforge now has a pretty bad reputation

    The bad reputation is largely obsolete. The owner had changed to a bad owner with bad practices, but that owner was eventually replaced by a better owner again.

    I still hate the UI though. We have much better alternatives today, which is why I don’t see any reason for anyone to go back to (or start) using Sourceforge. It’s no longer an issue of owner and bad practices, but solely of the platform itself with its UI/UX.






  • Package managers may distribute and manage libraries as dependencies, but may also manage tangential files like documentation, debug symbols, or source code for those libraries. They may also package build files to integrate into the build system, executable programs, or executable instructions. So it is a superset. Distributing libraries is the main, but only one aspect of them.

    A packaged library is distributable through the package manager.

    APIs, application programmable interfaces, are a standardization of callability - of names, parameters, returns, and behavior. Libraries may practically offer a non-standardized interface, or they may explicitly define an interface that they promise to follow (a more stable interface that you can depend on), or a library may implement an interface that is defined independently of a library.

    With a standardized interface, multiple libraries can implement the interface, and they become inter-operable and inter-changeable.

    OpenGL is an API that is defined as standards. The various graphics driver developers implement the interface. (Their driver makes the implementation available as libraries.) And there’s even software-implementations that implement a translation layer rather than “directly” talking to hardware. This for example allows you to play Windows games on Linux where the Windows APIs get translated to Linux equivalent API calls or implementations.

    Frameworks typically offer a broad[er] architecture and functionality of things. You do not interface with them, you integrate with them. For example, in C++ you may use the Qt framework for UI. Rather than using a UI library that you interface with and call, you implement UI the Qt way, and call Qt to render that. This does not only work for UI of course.