From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25821 invoked from network); 14 Aug 2021 18:13:24 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 14 Aug 2021 18:13:24 -0000 Received: from mail-io1-f52.google.com ([209.85.166.52]) by 1ess; Sat Aug 14 09:23:21 -0400 2021 Received: by mail-io1-f52.google.com with SMTP id x10so16967234iop.13 for <9front@9front.org>; Sat, 14 Aug 2021 06:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jkv4bg3u92zu2qGmiPikWKCxUEo5utLkNl2JlmdDJxs=; b=F9y8q3zpHz+ldQuJrBxDLHkh/xVvzYU+e9uxV0PRLHVhrxKb7durPY5ZRGrHquZG3q 5UKjuKhJVB3VVL4Ui4CUbzhTgGOb5fY3BqhwJECDO0XQ9b2Eu8bpU1Jacei+RZK5fmfA Ex60mpVEZHZoXf+0/6t+GJilmJo9lI1JvNDKRtTiviV0sXSlkoJfM4XImwnOr1gqRIip mUIivNP4FVUXYGd/yhSqgPdvXaraHKuLCm/Z4HzFJmrB4/+RwGnpVWklletuWNmyqJIk kzmq5lXRaz9HY9LfcIjSfsPMr7N73hFWvoLBw5kf46CteKXfJKc1Qf/SPSSXHONL5k1H /2aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jkv4bg3u92zu2qGmiPikWKCxUEo5utLkNl2JlmdDJxs=; b=H1SpXqN+UqX+rcj55uFzBbXKl9V3tllmHRLDcFxRNnbzRHQDhuN67AY038CZqhbI5E 3RLQCm//xw6ymeEQHqZAleB7O795wEA9Ht1kif+FjxKbrsKGdkp2Zo6mCWqVurVXU8ey xnMAWFtSMQxTSfRhC8IoZXxXccOVB0/MbwrYynXDs4GX5bftRVeZTJAC20VcBpdZPVRz 0uDK9+EcrTLq1oPLlOfM1dYN/LYPCcLd4iJSOw/MGfRhiCoVoDGFkFTkT3J+2vxzWgwA G0locUpBOmogf1Do5oSF6By683jEpYa5p68VXKTFRISszOJgnwoDZOZDWcV9wT6Lk0kU Uxpg== X-Gm-Message-State: AOAM533HAGvthcsCFDMMaWk2UUiqwZe4DliJdxCMbvqJ9MMKHSfRYhmj 4Kfz3waPiLDN+t21h4Kkxx0csKWgrxEMvLcDlS7S4Zk7 X-Google-Smtp-Source: ABdhPJyRwsZme0/5dggaJOMA3cERKOYHHfzeKbmu96arG7kZ8VOi6bYpQWskc/kFjp0RGCHQTYxkPduz+jD7YZGtNY0= X-Received: by 2002:a63:504a:: with SMTP id q10mr6756798pgl.383.1628947077776; Sat, 14 Aug 2021 06:17:57 -0700 (PDT) MIME-Version: 1.0 References: <20210812163626.63c3fb64@gmx.de> <9D0282916FEB7AB4CCD565BEE2B5889C@smtp.pobox.com> <20210814122014.621634c6@gmx.de> In-Reply-To: <20210814122014.621634c6@gmx.de> From: =?UTF-8?B?Sm9zw6kgTWlndWVsIFPDoW5jaGV6IEdhcmPDrWE=?= Date: Sat, 14 Aug 2021 15:17:46 +0200 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: immutable non-blocking AJAX scripting-based element framework Subject: Re: [9front] PATCH: click-to-focus in fgui Reply-To: 9front@9front.org Precedence: bulk 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 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. > > --