torios team mailing list archive

[Paul Sutton <zleap@xxxxxxxxxxx>]

Hi all

replies are inline

On 22/07/2020 00:28, Israel Dahl wrote:
> 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).
> 
So we have some text to speech support what about OCR support if that is
more mature,  what about building that in,  with OCR it also should
support pictures

I do agree about switching between the mobile (no keyboard) to the other
end which is full desktop.

> 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!
> 

Can we make it really easy to switch between boot to gui and boot to cli
pleasek  there is an option on the raspberry pi configuration tool
(which has both a curses (text) and gui widget, you just click a tick box.

Once instaled most distros (understandably) switch to gui by default but
there are probably use cases where this isn't needed, for example if you
are using mostly text based applications or just running applications
that don't even need the gui.

>>   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.
> 
So if we find the ones with similar goals, and can work together,  this
may prove that idea works and other groups of distros may be inspired to
do the same in their way.

> 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.
> 
agreed here,  the lxde people told me when i mentioned this on
sourceforge that there is a perfectly good text file to manually edit
the menu,  this is exactly the attitude that makes Linux seem elitist
rather than for everyone.


There is a menu editor (or several) but in general seems to be a
separate application and not installed by default.

>> 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.
> 

Good point,  I am guessing this is like running each application but
keeping the application isolated from other apps and to some extent the
wider system, for security reasons.

>> 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
> 

I will get something set up on cryptdrive for this,  we can always move
later but if it works for initial brainstorming that is a good thing.


Regards

Paul

-- 
Paul Sutton
https://personaljournal.ca/paulsutton/
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D