Termite Is Obsoleted by Alacritty

• alacritty

  361 55,886 8.9 Rust

  A cross-platform, OpenGL terminal emulator.

  

  Yeah, their original benchmarks were, uh...

  > Benchmarks so far have just involved running find /usr on my Linux system with Alacritty, st, and urxvt, and on macOS against Terminal.app and iTerm2.

  https://github.com/alacritty/alacritty/issues/289#issuecomme...

  They decided to continue marketing it as the fastest terminal emulator anyway.

  > > Correct accuracy of first sentence in README #798

  > >

  > > As documented in #289 it's not currently the fastest-- only a small number of terminals running a single task for initially benchmarked.

  >

  > nah

  https://github.com/alacritty/alacritty/pull/798

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

• termite

  35 2,850 1.1 C++

  Discontinued Termite is obsoleted by Alacritty. Termite was a keyboard-centric VTE-based terminal, aimed at use within a window manager with tiling and/or tabbing support.

• dotfiles

  1 14 4.8 Python

  My personal configuration files (by dbrgn)

  > 2) No emoji colors

  Colored emoji are working fine in my alacritty terminal. Here's my fontconfig file: https://github.com/dbrgn/dotfiles/blob/master/fonts.conf

• mpv

  848 28,058 9.9 C

  🎥 Command line video player

  

  https://github.com/mpv-player/mpv/pull/7186

  Needless to say, mpv prefers xdg-decoration if compositor supports it.

  >There aren't any zero code solutions

  It's zero-code for client if the compositor actually handled the border. And yes, compositor is the more likely component to actually have the foundation to do this kind of task.. I mean it is an _compositor_.

  >The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries

  Yes and hope those libraries actually implement stable ABI. SDL may do this, but it's actually a maintenance nightmare. If you actually go this way, it's better to have wrapper libraries that link to the actual libraries instead and dlopen those wrapper libraries. Though I also aren't really fan of shared libraries, but that's entirely different topic.

• wlroots

  107 1,969 9.8 C

  Discontinued A modular Wayland compositor library

  

  If last time you tried using Wayland was Sway, maybe this is the issue you were running into: https://github.com/swaywm/wlroots/issues/2889

  TL;DR: Drag and drop involving chromium or electron windows has been buggy. wlroots/sway has not implemented _NET_CLIENT_LIST_STACKING, and both the fallback code inside Chrome/Chromium and the way sway has been stacking Xwayland windows have been buggy. A patch has been submitted to Chromium to fix the faulty fallback, the sway bug will be fixed, and wlroots will also support _NET_CLIENT_LIST_STACKING, so by the time the next sway release comes out everything should be ironed out.

• kitty

  302 24,114 9.9 Python

  Cross-platform, fast, feature-rich, GPU based terminal

  I hope it "obsoletes" kitty as well https://github.com/kovidgoyal/kitty/pull/3544#issuecomment-8...

• Windows-10

  11 819 4.4 CSS

  Windows 10 Light theme for Linux (GTK)

  

  I'm sorry, I misunderstood. There is currently no way to make all the widgets render to look like Windows widgets. You probably don't want to do that anyway.

  There is another solution. Somebody could make a theme that makes the widgets look like Windows, and ship that with their windows builds, if that was desired. There are multiple themes like this for GTK3. [0] [1] I don't know if any have been ported to GTK4 yet, but they could.

  [0] https://github.com/B00merang-Project/Windows-10 [1] https://github.com/B00merang-Project/Windows-7

• Windows-7

  9 136 2.6 CSS

  Linux theme based on the apperance of Windows 7

  

  I'm sorry, I misunderstood. There is currently no way to make all the widgets render to look like Windows widgets. You probably don't want to do that anyway.

  There is another solution. Somebody could make a theme that makes the widgets look like Windows, and ship that with their windows builds, if that was desired. There are multiple themes like this for GTK3. [0] [1] I don't know if any have been ported to GTK4 yet, but they could.

  [0] https://github.com/B00merang-Project/Windows-10 [1] https://github.com/B00merang-Project/Windows-7

• static-haskell-nix

  7 389 7.4 Nix

  easily build most Haskell programs into fully static Linux executables

  I think there's a misunderstanding: Most people want to use the .a file from their Linux/package distro that provides static libraries, such as Alpine Linux or nixpkgs.

  Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`.

  > if they could keep that libgtk_static around

  Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious.

  > I'd be interested to hear if static linking GTK even has that many benefits

  One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere.

  Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed.

  This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so.

  [1] https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...

Suggest a related project