From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 4B298271F2 for ; Sat, 18 May 2024 20:53:57 +0200 (CEST) Received: from estafeta.antares-labs.eu ([65.20.100.6]) by 9front; Sat May 18 14:53:00 -0400 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antares-labs.eu; s=estafeta; t=1716058375; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GLkhwDuGuBDJmmrl7sAsmcNIVqBFEm+Ev/4wFxptUbI=; b=KcHbAkWr8BKSxGLmSwgn/vMUvOepJvHtHy9uKFdxRwpXrhdnfuecNSIeGkWkN0gpTfLXP4 s442SSOA4TABxzScUfE9tvGoAYL8i+wOWJG8BFcsGGr2MqLMq4VopoYJ+ZJ+mR+HfpCg0y 2ArXXeV+15Dmm6BXteZPQ+SeX9oHVKE= Received: from [IPv6:::1] ( [2a0c:5a84:d106:aa00:610a:bc98:7a92:3f93]) by estafeta.antares-labs.eu (OpenSMTPD) with ESMTPSA id 718d3156 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 18 May 2024 18:52:55 +0000 (UTC) Date: Sat, 18 May 2024 18:43:15 +0000 From: =?ISO-8859-1?Q?Rodrigo_G=2E_L=F3pez?= To: 9front@9front.org, qwx@sciops.net In-Reply-To: References: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: HTML over SOAP cloud just-in-time session blockchain-oriented controller Subject: Re: [9front] qball(2) bounced back Reply-To: 9front@9front.org Precedence: bulk i guess it's a matter of keeping it simple, i mean, ideally i would not put= it in any of those places, but take the input devices/controls out of libd= raw and into their own libui (or whatever we could call it) and add it ther= e=2E the qball is very much a graphics thing, and libgeometry's job is to focus= on geometry, not visualization=E2=80=94related as they are=2E graphics lib= raries should depend on it, not the other way around=2E =E2=80=A6but maybe i'm being too pedantic=2E i will add all of this eventually, as long as it's welcome (it's a lot of = code), so i was thinking i put it in libgraphics, then merge it when the ti= me comes=2E :) -rodri On May 18, 2024 3:49:02 PM UTC, qwx@sciops=2Enet wrote: >On Sat May 18 12:06:14 +0200 2024, rgl@antares-labs=2Eeu wrote: >> hello everyone, >>=20 >> i recently fixed the qball, after almost a year and a half of me saying= i would: >>=20 >> http://git=2Eantares-labs=2Eeu/3dee/plain/qball=2Ec >>=20 >> it is consistent with the conventions used in libgeometry, and it works= by >> default when looking at a model from the positive z-axis (just like Sho= emake's)=2E >>=20 >> the thing is, i've been thinking about it, and it doesn't make sense to >> put it in there=2E it is actually a perfect fit for mouse=2Eh with its = menuhit(2) >> and enter(2) routines; the problem is that this would make libdraw depe= nd on >> libgeometry, or require to keep a copy of the Quaternion procedures use= d for >> the qball=E2=80=94and make sure they are in sync with libgeometry=2E > >Awesome, 3dee is really cool :) Performance isn't great but it works >nicely=2E > >Why not leave qball in libgeometry? Isn't it implicit that you'd be >using both libgeometry and mouse+keyboard with qball anyway? If so, >imho it's fine=2E libdraw et al aren't as cleanly delineated as they >could be, so these sorts of dependencies are common=2E > >I'd personally be happy to see all of this part of the distro, it's >very interesting and throrougly in plan9 style, but it's just my >opinion (minus some of the model files of course)=2E > >Cheers, >qwx