guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Organizing Tui Apps


From: Leo Prikler
Subject: Re: Organizing Tui Apps
Date: Sat, 24 Apr 2021 09:12:56 +0200
User-agent: Evolution 3.34.2

Am Samstag, den 24.04.2021, 01:50 +0000 schrieb Ryan Prior:
> On April 23, 2021, Leo Famulari <leo@famulari.name> wrote:
> > On Fri, Apr 23, 2021 at 10:00:14PM +0200, Leo Prikler wrote:
> > > Spreadsheets sounds fine to me, but I think the most important
> > ones
> > > (libreoffice and org-mode) are already excluded from that module
> > for
> > > obvious reasons ;)
> > > Perhaps an even more generic "office" module might be better,
> > because
> > > then we could at least add some small word processors to it,
> > WDYT? Or
> > > maybe sc-im already fits as-is into textutils if you squint hard
> > enough
> > 
> > My main objection was about moving packages. So whatever module you
> > create is fine, but let's not start moving libreoffice and org-mode
> > around.
> 
> As the person who originally suggested organizing tui-apps into a
> file, I'd envisioned it as being sort of like its own desktop
> environment. So similar to how we might put Gnome (GTK) apps and KDE
> (Qt) apps together, we might put tui (ASCII terminal) apps together.
I don't think that makes too much sense.  GNOME, MATE, XFCE, Unity,
Cinnamon etc. are all GTK-based toolkits, but their mere size warrants
to put them into their own modules (at least for some, probably).
I also don't think, that TUI apps form a cohesive interface as there
are few "collective guidelines" for how a TUI app should look like. 
See ncmpc and ncmpcpp for an example of two TUI apps serving the same
purpose but looking very different.

> I am not upset if that's unconvincing to others & will happily drop
> the proposal if it's not useful, I never intended for it to become a
> drawn out discussion. It also makes sense to me that we might
> organize things by programming language or by function, those each
> have strengths as strategies.
Supposing sc-im was programmed in Rust (it is not afaik, but suppose it
was), putting it into rust-apps would probably be fine.

Regards,
Leo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]