9front - general discussion about 9front
 help / color / mirror / Atom feed
From: "José Miguel Sánchez García" <soy.jmi2k@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] PATCH: click-to-focus in fgui
Date: Sat, 14 Aug 2021 15:17:46 +0200	[thread overview]
Message-ID: <CAA85C87T8hbUaL8=UC_bBKhgHjke+q57F54dz5cOBHpApbcPXg@mail.gmail.com> (raw)
In-Reply-To: <20210814122014.621634c6@gmx.de>

My argument against focus-follows-mouse is that it's inconsistent with
how everything works in 9, and IMHO, 9 is about consistency:
"everything is a file" is a cool slogan for "we have a consistent
model to label and locate resources". Rio doesn't have a lot of fancy
features because it aims to be a simple and predictable "rectangle
multiplexer" (as sl says in his webpage). The plumber is a consistent,
system-wide hyperlinking solution.

Wanting focus-follows-mouse is reasonable. Wanting in-tree support for
that in 9, not so much. #ifdefs are pointless, as they are a kind of
sloppy, inline patch that makes the code harder to understand. I think
patching is the way to go. And I'm personally one of those who keep a
collection of patches I apply automatically after each 9front
installation because I love customizing my system (currently I'm
changing colors, menus, keybinds...).

Cheers,
jmi2k

On Sat, Aug 14, 2021 at 2:24 PM Eckard Brauer <eckard.brauer@gmx.de> wrote:
>
> Am Fri, 13 Aug 2021 09:10:47 +0200
> schrieb hiro <23hiro@gmail.com>:
> > of course it's possible! and who cares what's approved?! and we
> > definitely don't approve of #ifdefs, so what is this? some form of
> > trolling?
>
> So far you're free to treat that as whatever you want. As you seem to
> hate the discussion and maybe the participants of it, it's probably of
> much more value if you sit down and write a Plan9 bible with all se
> do's and dont's well ordered by precedence. That way you could have a
> better chance to avoid such discussions for the future and simply
> remind people to "read the fucking guide of dogmas".
>
> regarding the #ifdefs, I completely conform with the idea of mostly
> avoiding them. My suggestion was _never_ to introduce them, but to have
> different choice possible (see the typo, corrected here) "with patch or
> [..] #ifdefs", so either possibility could have been fine, and the
> default behaviour would be kept.
>
> > the tradition on plan9 is to have one single, consistent, sane default
> > whenever possible, so nope... making it user configurable goes against
> > everything we stand for.
>
> OK, but see above with documentation. If the topic is that dogmatically
> overloaded, it _needs_ to be documented in somewhere strictly before
> all user guides and the like. But, hey, why then does rio have a -b
> option or do patches for changing the color scheme exist? It's not
> standard anymore... or why does Plan 9 support keyboard layouts at all
> and doesn't enforce all keyboards of US type? OK, I see some of the
> differences, but you will always hit points where to decide to support
> something formerly unsupported and not covered by any explicit or
> implicit (single-brain?) standard.
>
> Simply think of networking hardware and see what was supported years
> before, what is now, and what probably will be some years later. That's
> btw my personal reason for not actually being able to switch to Plan 9
> for my everyday OS, as I could well live with click-to-focus, if it
> were the only point. That's indeed not a matter of only user
> experience, but of hardware support, but why trying to support many new
> hardware, but not the users, when maybe a large enough group has
> different ideas of usability?
>
> That's a matter of flexibility too, and strictly enfocing the "one and
> only way" everywhere will maybe lead to the most efficient "one man's
> OS". Please come up with real arguments, not "it was everytime this way
> and not different, and so it has to remain". That's really shitty.
> Nobody can resist good reasons and explanations, and if there's a dogma
> left to _never_at_no_single_time_ support something, it has at least to
> be stated somewhere, well visible and clear for every single person.
>
> > if you want to experiment with shitty windowmanagers that get all
> > triggerhappy whenever you look at your mouse sideways there's a lot
> > out there for linux that you could try. please do this first (like
> > most other people have already done here) and feel the suffering
> > before you share more opinions.
>
> As already written, it's _not_ a matter of supporting all "shitty
> windowmanagers" or "but my Windoze has that" or such. As I'm currently
> unable to use Plan 9 as my everyday OS, I'm currently on Linux. I hate
> that and would be willing to switch, if some more things work. And I
> simply exposed an opinion of how I'm working most of the time. If that
> is enough to disqualify me from talking here, please send a note and
> drop me from that list, if not, tell arguments and get it documented at
> where that belongs.
>
> Up to now, I didn't find a strong counterargument against a different
> focus policy, but am still open to know that.
>
> --

  parent reply	other threads:[~2021-08-14 18:13 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09 22:59 Silas McCroskey
2021-08-10 14:19 ` ori
2021-08-11  5:28   ` rgl
2021-08-11 20:49     ` Philip Silva
2021-08-11 21:09       ` Steve Simon
2021-08-11 22:37       ` Xiao-Yong Jin
2021-08-12  9:05         ` hiro
2021-08-12 14:36           ` Eckard Brauer
2021-08-13  6:44             ` unobe
2021-08-13  7:10               ` hiro
2021-08-14 10:20                 ` Eckard Brauer
2021-08-14 13:09                   ` qwx
2021-08-14 15:03                     ` Stuart Morrow
2021-08-14 13:17                   ` José Miguel Sánchez García [this message]
2021-08-14 20:57                     ` Patch-keeping (Was Re: [9front] PATCH: click-to-focus in fgui) unobe
2021-08-14 15:04                   ` [9front] PATCH: click-to-focus in fgui Stuart Morrow
2021-08-14 18:08                   ` hiro
2021-08-14 21:43                     ` unobe
2021-08-15  6:47                       ` hiro
2021-08-14 21:46                   ` unobe
2021-08-15 13:36                     ` Eckard Brauer
2021-08-15 19:16                       ` hiro
2021-08-15 17:31                   ` kvik
2021-08-15 18:34                     ` Kurt H Maier
2021-08-15 18:48                     ` Stanley Lieber
2021-08-15 20:18                       ` Eckard Brauer
2021-08-15 22:35                         ` Stanley Lieber
2021-08-16  5:14                           ` Stanley Lieber
2021-08-16 15:46                             ` Skylar Bleed
2021-08-15 19:03                     ` hiro
2021-08-16 16:40                       ` kvik
2021-08-16 19:25                         ` Stuart Morrow
2021-08-16 19:40                           ` Kurt H Maier
2021-08-17  2:05                             ` Stanley Lieber
2021-08-16 20:04                         ` hiro
2021-08-16 20:13                         ` hiro
2021-08-17  1:10                           ` Xiao-Yong Jin
2021-08-17  8:11                             ` hiro
2021-08-12  0:12       ` hiro
2021-08-15  4:29       ` ori
2021-08-16 19:40 ` ori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA85C87T8hbUaL8=UC_bBKhgHjke+q57F54dz5cOBHpApbcPXg@mail.gmail.com' \
    --to=soy.jmi2k@gmail.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).