4 ms·

The strangest thing to me though is that the OP finished this work last year and sat on it until very recently. They explain it as "I wrote this for a client an

The strangest thing to me though is that the OP finished this work last year and sat on it until very recently. They explain it as "I wrote this for a client and didn't feel like sharing it." That attitude seems a bit in contrast to the purported motivation to, "Make it so people don't suffer like I did in school." So I guess in a way OP is (sort of) seeing the light on free software here too. Don't like it? Fork it!

_2paq 5y ago
Hard forks rarely get traction and are almost always lost in obscurity, unless the original project itself is abandoned. tmux isn't abandoned so I doubt this fork will end up being used by more than a handful of people. EDIT: Yup, as suspected, the author doesn't intend to keep his fork updated with upstream and I don't blame him for that. This essentially makes this fork a proof of concept, nothing more. Unless it gets merged in tmux itself, people might as well forget that this fork exists. https://github.com/csdvrx/sixel-tmux/pull/1 https://github.com/csdvrx/sixel-tmux/pull/1
- csdvrx 5y ago
  Thanks for being understanding. To be honest, Windows fangirl? guilty as charged! But I try to keep my personal opinions separate, which is why my rants are on a separate page. Still, you nailed it: sixel-tmux was made to try to help correct the direction that has been taken, with 6 years wasted. I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool". Desperate times call for desperate measures. Publishing this fork was a last resort move, for the exact reasons you stated: forks are often lost in obscurity. However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel! A compile time flag is not ideal, but if at least derasterize can be added by default, so that every tmux user can have some kind of graphics in the terminal, even if said graphics are not sixels but derasterized, that would be "good enough" to me.
  - _2paq 5y ago
    > Thanks for being understanding. No problem. I know maintaining forks isn't an ideal thing to do and support should ideally land upstream. > I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool". I think the README page of termite pretty much sums up why getting involved in VTE, or any GNOME project for that matter, is a bad decision. https://github.com/thestinger/termite/blob/master/README.rst#termite-is-obsoleted-by-alacritty https://github.com/thestinger/termite/blob/master/README.rst... I'm just a random spectator but perhaps your efforts might've been better spent on an independent terminal project (like Alacritty, for example) rather than trying to get features merged upstream in a GNOME project. > However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel! Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news.
    - csdvrx 5y ago
      > I think the README page of termite pretty much sums up why getting involved in VTE, or any GNOME project for that matter, is a bad decision. > > https://github.com/thestinger/termite/blob/master/README.rst#termite-is-obsoleted-by-alacritty https://github.com/thestinger/termite/blob/master/README.rst... Wow, this confirms a lot of my impressions: >> In 2012, we submitted a tiny patch exposing the APIs needed for the keyboard text selection, hints mode and other features. Despite support from multiple other projects, the patch was rejected. It's now almost a decade later and no progress has been made. There is no implementation of these kinds of features in VTE and it's unlikely they'll be provided either internally or as flexible APIs. This is the tip of the iceberg when it comes to their hostility towards other projects using VTE as a library. GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use. This is exactly why sixel-tmux exists as a separate entity! > Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news. I'll keep my fingers crossed, but right now, there seems to be a lot of good will. I will do everything I can.
  - 5y ago

_2paq 5y ago

Hard forks rarely get traction and are almost always lost in obscurity, unless the original project itself is abandoned. tmux isn't abandoned so I doubt this fork will end up being used by more than a handful of people. EDIT: Yup, as suspected, the author doesn't intend to keep his fork updated with upstream and I don't blame him for that. This essentially makes this fork a proof of concept, nothing more. Unless it gets merged in tmux itself, people might as well forget that this fork exists. https://github.com/csdvrx/sixel-tmux/pull/1 https://github.com/csdvrx/sixel-tmux/pull/1

csdvrx 5y ago
Thanks for being understanding. To be honest, Windows fangirl? guilty as charged! But I try to keep my personal opinions separate, which is why my rants are on a separate page. Still, you nailed it: sixel-tmux was made to try to help correct the direction that has been taken, with 6 years wasted. I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool". Desperate times call for desperate measures. Publishing this fork was a last resort move, for the exact reasons you stated: forks are often lost in obscurity. However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel! A compile time flag is not ideal, but if at least derasterize can be added by default, so that every tmux user can have some kind of graphics in the terminal, even if said graphics are not sixels but derasterized, that would be "good enough" to me.
- _2paq 5y ago
  > Thanks for being understanding. No problem. I know maintaining forks isn't an ideal thing to do and support should ideally land upstream. > I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool". I think the README page of termite pretty much sums up why getting involved in VTE, or any GNOME project for that matter, is a bad decision. https://github.com/thestinger/termite/blob/master/README.rst#termite-is-obsoleted-by-alacritty https://github.com/thestinger/termite/blob/master/README.rst... I'm just a random spectator but perhaps your efforts might've been better spent on an independent terminal project (like Alacritty, for example) rather than trying to get features merged upstream in a GNOME project. > However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel! Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news.
  - csdvrx 5y ago
    > I think the README page of termite pretty much sums up why getting involved in VTE, or any GNOME project for that matter, is a bad decision. > > https://github.com/thestinger/termite/blob/master/README.rst#termite-is-obsoleted-by-alacritty https://github.com/thestinger/termite/blob/master/README.rst... Wow, this confirms a lot of my impressions: >> In 2012, we submitted a tiny patch exposing the APIs needed for the keyboard text selection, hints mode and other features. Despite support from multiple other projects, the patch was rejected. It's now almost a decade later and no progress has been made. There is no implementation of these kinds of features in VTE and it's unlikely they'll be provided either internally or as flexible APIs. This is the tip of the iceberg when it comes to their hostility towards other projects using VTE as a library. GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use. This is exactly why sixel-tmux exists as a separate entity! > Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news. I'll keep my fingers crossed, but right now, there seems to be a lot of good will. I will do everything I can.
- 5y ago