torios-dev team mailing list archive

[Israel <israeldahl@xxxxxxxxx>]

Hi Nio,
(inlines as well)
On 08/17/2018 02:22 AM, Nio Wiklund wrote:
> Hi Israel,
>
> [Answering inline]
>
> Best regards
> Nio
>
> Den 2018-08-17 kl. 03:12, skrev Israel:
(snip)
>> It is possible to rework the program to remake things to avoid
>> patching FLTK and using a static library (by making extended classes
>> rather than patching the code) AFAIK, and perhaps get upstream FLTK
>> devs on board and include the changes.  Currently it supports
>> indicator icons via using GTK libs, but not the entire library, and I
>> have suggested using code similar to mine for the indicators.
>
> I am afraid, that it is a lot of work to remake all programs and
> scripts that depend on GTK to FLTK. Is it worth spending all that time
> and work on that task rather than upgrading ToriOS to work based on
> newer versions of Debian (or Ubuntu) and polishing ToriOS?
>
I agree that it is a lot of work.  However, I have recently built a
bunch of small programs to handle most of the things we need.
The last programs needed are the calendar (handled by fltk-dialog) and
the graphical front ends to install and update software (also can be
easily replaced by fltk-dialog).
All the existing programs have been modified to check for the new binary
programs I made (though this change has not been pushed into the repos yet).

So the workload is mostly limited to 2 scripts.... excluding of course
mkusb and OBI
>> Basically I think we could convert our tools (mkusb/OBI/etc..) to use
>> fltk-dialog and save a lot of space if we can completely migrate away
>> from GTK, though the main issue here will be PCManFM.  It would be
>> really great to have a fully non GTK DE that rivals the GTK LXDE and
>> can easily run on older hardware in very strong and clean way.
>>
>> This will require some serious thought, and as Ali and Nio discussed
>> earlier it might be time to look into using di (Debian Installer) to
>> install ToriOS, rather than OBI, since things have changed.  We could
>> (potentially) make an FLTK front end, though this is a rather
>> imposing idea since most Debian docs about their internal tools are
>> rather lame (such as apt-pkg).
>
> A question about mkusb: I have seen zero interest from ToriOS users in
> the persistent live feature. If this is correct, we could make a much
> simplified version of mkusb from the basics, and that version can be
> created with a light-weight GUI (FLTK, if/as you wish).
>
I think this would be good to do.  It would be nice to make it all use
C/C++ interfaces to do it rather than external programs
(dd/pv/zenity/etc).  But that may be rather complicated.  So an interim
program to handle basic functions might be nice (though I really like
guidus/mkusb as is)
> I still think we should look into alternative installers (and replace
> the OBI). We should pick an installer, that already exists and is used
> by other linux distros, and that is able to install both in BIOS mode
> and UEFI mode.
>
Yes.  I think this is a great idea!  I would like to pick an upstream
project actively maintained and kept up so that we could focus on
building only the ISO (rather than the current build OS and ISO).  It
would cut our build time in half, and speed up ISO creation, since I am
the only one who does it (when I am afforded the time involved).

If anyone could research alternative installers, and give me a list of
links to the best ones (API, or developer documentation links are
especially handy for me) I would appreciate this.  I am going to be
pretty busy for a bit, but I will try to keep working on things.

Thanks Nio for the response, you offer a very good perspective.

-- 
Regards