Off-Topic > Off-Topic - Tiny Tux's Corner

Slitaz Revisited

(1/5) > >>

Inspired by my Chromebox running an earlier version of TinyCore due to kernel size limitations, I also am running the latest version of Slitaz on it as well.

Sure, it's still running kernel 3.16.55 which just went EOL, but the bits don't die - they still boot the box.  And busybox is maintained close to the very latest.  Small things like nano at 4.8 (which I don't use, but it's there and fresh).  But this isn't about Slitaz overall even though I find it fascinating to use.

But this is more about something I think gets overlooked about Slitaz:  The "TazPanel".  Basically Slitaz relies upon Midori to do the cgi-html scripting in for many of the system utilities, such as package management, hardware support, bootlogs, and a variety of other things.

Ie, instead of relying on lua/fltk kinds of gui programming, many tools available are simply using cgi-html scripting instead in the panel.

It kind of makes me want to put front-ends on some of my stuff - maybe trying to duplicate the TC control panel stuff.  Instead of cat'ing system files in a terminal, maybe just create an html file with a link to them?

I don't know what I'd choose though:  Lynx, elinks, Dillo, Midori  -- something small that can reside outside of the big ones.

Maybe I'll have to dig out that "Learn HTML in 24 hours" book under the couch and get to work. :)

html menu or configs sound nice, no need to compile fltk appls. but because html is basically text + few tags you can have both worlds ("graphic view" and text menu files). and yes, lynx and and dillo will be enough to use html, created by nano, which you love  :)

BTW, you can "learn" the basic html you need, in 1-2 hours. because you do not need all html powerfully functions, or CSS formatting.

EDIT: my idea is to use FLWM (the menu) to call sh scripts (no browser need). I think few people discussed or implemented additional menu/submenus in TC normal menus (Appls + Ondemand + System). But is it so easy. This path is hugely not exploited yet.

something like in attachment.

I am sure that additional FLWM menus and sub-menus can be AUTOMATICALLY created by scripts, from simple rules of *desktop as defined by freedesktop foundation. Same as they are dynamically created by dmenu or XFCE menus for program categories etc.

I am lazy, not so good at programming, so for myself I could just create them fixed/manual by categories like
browsers -> dillo, Firefox, elinks,
offices -> libreoffice, gnumeric, abiword
emulators -> qemu, tinydos, virtualbox
cdrom-appls -> mkisofs,etc
image-viewers: feh
video-audio: vlc, mplayer, xmms
pdf-tools: mupdf, flaxPDF file-managers

The advantage is that i do not have a huge and UN-sorted ondemand list.
These new menus can be also on demand conditionally. basically is ondemand splitted by categories

I've always like html programming, even if simple.  I come from the days of when documents were 90% content, and 10% markup.

These days, it's 10% content, and 90% markup. :)

Unfortunately, many were lead to believe that an efficient html system can only be made by html writing programs, rather than doing it yourself with nothing but say vi / nano and dillo.  Heh, remember seeing tags with "Lynx Friendly" ?

If one keeps to kiss standards, the system could be long-lived and nearly portable.

Ironically, when Chromebooks first started to appear, the dev who proposed it to Google was designing it as a small system which relied not only on the browser to do that function, but be part of the overall end-user setup, rather than rely on custom gui programming.

Makes me wonder if Slitaz introduced near that timeframe had any influence?

I'll have to think about it.  Perhaps instead of Midori as the system-level browser / programmer, I might think about NetSurf.  Dillo is cool, but maybe these 2 browsers might be easier to work with - and of course as long as they don't hog ram doing so.


[0] Message Index

[#] Next page

Go to full version