3 ms·

I dug in and read the linked thread and patch, and this may be a bit in the weeds, but nobody on the linked thread called out Christian Persch's comment [1] whi

I dug in and read the linked thread and patch, and this may be a bit in the weeds, but nobody on the linked thread called out Christian Persch's comment [1] which doesn't make much sense to me. To be completely fair, this is a comment from 2015, 12 comments deep in an otherwise relatively isolated bugzilla forum, so maybe we shouldn't judge too harshly. Anyways, have a look: > In reply to Daniel Micay from comment #10: > > Implementing this in VTE would mean ruling out having any flexibility in the > > terminal using the library. I haven't responded any more here because an > > implementation inside VTE won't satisfy the use case. > > Implementing keyboard selection inside vte means that *every* terminal based > on vte benefits; adding only hooks for you means that all the other terminals > get *no* benefit. This seems like a pretty shallow argument. What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? Or, stated another way, why is gnome terminal entitled to receive all the features built on top of GTK component apis used by other projects? He's stating the conclusion that VTE is the correct layer to implement the end-user highlight/selection feature without actually making an explicit case for it, and without acknowledging that there's an argument that the layer above could actually be a better location to implement the feature. Thoughts? [1]: https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12 https://bugzilla.gnome.org/show_bug.cgi?id=679658#c12

zxzax 6y ago
>What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? They could but then every terminal would have to re-implement the same feature causing needless code duplication. You can see here later a comment from the tilix developer that explains it: https://github.com/gnunn1/tilix/issues/848#issuecomment-289286939 https://github.com/gnunn1/tilix/issues/848#issuecomment-2892...
- infogulch 6y ago
  Yes that's the case Christian was making (implicitly). Another case could be that (1) maybe there isn't only one right way to implement such a feature, and (2) pulling the implementation down into the component layer leaves no space for experimentation or choice between different potential implementations, and (3) given the enormous pain of making any modifications in the GTK component layer (as this issue clearly demonstrates) I can sympathize with a dev that uses the component in their app shying away from the prospect of running every single idea through such a painful interaction every time they want to experiment with something. One might argue that there's a better api somewhere between "exposing raw block selection functions" and "fully-baked selection feature" that covers most needs and still provides desired flexibility, but (4) you don't find such an ideal api by theorizing from first principles, you have to derive it from experience and nobody can get such experience unless the lower-level api is available in the first place.
  - zxzax 6y ago
    I don't have any particular opinion on the best way to do this, but from those comments by the tilix developer, it doesn't seem like the approach taken by vte-ng was the right one either. From the VTE maintainer's perspective, adding any additional external symbols can create trouble, because those symbols have to be maintained for the duration of the major version, and they can prevent further refactorings. It's usually not easy to get public API changes into old libraries like this.
    - infogulch 6y ago
      These things are certainly reasonable to consider. Thanks for adding additional context.

zxzax 6y ago

>What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available? They could but then every terminal would have to re-implement the same feature causing needless code duplication. You can see here later a comment from the tilix developer that explains it: https://github.com/gnunn1/tilix/issues/848#issuecomment-289286939 https://github.com/gnunn1/tilix/issues/848#issuecomment-2892...

infogulch 6y ago
Yes that's the case Christian was making (implicitly). Another case could be that (1) maybe there isn't only one right way to implement such a feature, and (2) pulling the implementation down into the component layer leaves no space for experimentation or choice between different potential implementations, and (3) given the enormous pain of making any modifications in the GTK component layer (as this issue clearly demonstrates) I can sympathize with a dev that uses the component in their app shying away from the prospect of running every single idea through such a painful interaction every time they want to experiment with something. One might argue that there's a better api somewhere between "exposing raw block selection functions" and "fully-baked selection feature" that covers most needs and still provides desired flexibility, but (4) you don't find such an ideal api by theorizing from first principles, you have to derive it from experience and nobody can get such experience unless the lower-level api is available in the first place.
- zxzax 6y ago
  I don't have any particular opinion on the best way to do this, but from those comments by the tilix developer, it doesn't seem like the approach taken by vte-ng was the right one either. From the VTE maintainer's perspective, adding any additional external symbols can create trouble, because those symbols have to be maintained for the duration of the major version, and they can prevent further refactorings. It's usually not easy to get public API changes into old libraries like this.
  - infogulch 6y ago
    These things are certainly reasonable to consider. Thanks for adding additional context.