torios team mailing list archive
-
torios team
-
Mailing list archive
-
Message #02707
Re: Time Investment
Hi,
Haven't read the second one yet, so I may repeat...
(inlines)
On 7/21/20 2:02 PM, ml@xxxxxxxxxxxx wrote:
> On Tue, July 21, 2020 9:42 am, Israel Dahl wrote:
>> Yeah, so lets focus on the operating system (snip)
> Having done development for both desktop and mobile, I don't believe
> screen size is the biggest issue when porting between the systems. I
> believe the user input paradigm is much more of a problem. You're going
> from a desktop extreme where some user wants everything input by keyboard
> (possibly no mouse support) to a normal desktop where apps use mouse and
> GUI and possibly CUA style menus for input to a mobile extreme where there
> is no keyboard. Supporting all these options and doing each well in the
> same application can be very difficult. I'd like to see better
> speech-to-text recognition solutions as that would solve some of the
> missing keyboard problems with mobile. The technology is there, but not
> fully in Free Software and not fully in systems that don't make use of the
> Internet to spread processing to several machines (which could bring up
> privacy issues).
Ok, so a low resource UI toolkit that automatically switched 'modes'
would benefit everyone. There are x86 machines that use small screens
(aren't ATM x86, since they use Windows?... I could be wrong), as well
as ARM. If the top menu bar turned into a hamburger button on window
sizes smaller than the menu, it would be easy:
if screen < menu_size:
switch(menu, button)
else
switch(button, menu)
You could do it to FLTK classes pretty easily.
>> If the small distros get together I think the collaborative effort would
>> go leaps and bounds to solve our common issues. A simple GUI toolkit could
>> be probably written by you and technosaurus over @ puppy, and accept
>> command line arguments for scripting (he's things like it before with lots
>> of little examples).
> Now this is where you run into a problem with collaboration. While
> everyone may have similar large goals when you get to the design
> trade-offs, you're going to have trouble getting a group consensus.
I'm thinking Unix philosophy here bring all the small parts together, so
we can find the common tweaks, and all the little bits we have in common.
We might find more in common if we start at the basics. I know the
UI/Shell stuff is not supposed to have consensus :D But we all need to
start our Window Managers, and need a lightweight login/lock screen,
etc... Your site is an example of what I'm talking about!
> I
> believe Technosaurus prefers working with X11 and its libraries. At the
> moment, I'm concentrating on SDL and OpenGL. We could each write a simple
> GUI toolkit, but unless we had a similar design philosophy and a similar
> list of design trade-offs and goals, it would be very hard to collaborate
> and put together one GUI library that handles everything we'd both want
> from it.
Or make a go between. Make a simple library that made a window, but you
could have devs add in their favorite toolkits via #define
Make a collaborative effort. It doesn't need to support more than you
want. A simple dialog-type library that can be easily used in more
complicated programs would be great!
> I think you'd have the same issue uniting small distributions. If you
> find ones with similar goals, you can share with each other. If they're
> developing things that don't fit your design philosophy or vice versa,
> it's difficult to reuse work.
I see so many things that bleed over, for example menu generation.
Why is there no central libraries for menu generation in multiple
languages that are optimized? Everyone is doing it by hand. Even a
POSIX shell library for it would be great! (You could add more 'bling'
by sourcing more components for your menu implementation) Then every
distro/menu app could reuse safe well written code. Every user could
make their own menu program if they wanted.
> Israel, you mentioned staying away from BSD components.
No, I mean personally. Just me, not ToriOS :D
> That makes it
> hard to share with a project like nenuzhnix because they stay away from
> GNU components. For instance, I mentioned nano and it will not be a part
> of nenuzhnix because it's a GNU project.
We can choose MIT/etc and work together on core things. We both do
similar things.
Think about it, if Debian, RHEL, Ubuntu, Suse, and Arch worked together
on a safer chroot/jail that worked cross distro, it would help everyone.
> Paul, I like your idea of taking the highlights or the important decisions
> from the e-mail discussions and putting it all in one place everyone can
> get to. Would also be nice if we can make some of our goals or decisions
> accessible via the web so we can refer other distributions to the
> information and see if they want to collaborate as well.
>
++1
--
Regards,
Israel
Follow ups
References