KLV-Airedale-rc4.1 with Void Linux Kernel is Available!

[rockedge]

KLV-Airedale-rc4.1
Kennel Linux Void Airedale Release Candidate 3 755 MiB download size ↓
KLV-Airedale-rc4.1
SHA1-MD5.txt

starting of the pulseaudio system for any user that is logged in has been fixed and improved. Thanks wiak, Sofiya and fredx181 for the exact steps.

Upgraded to a new version of @fredx181 's save2flash, and set LANG=en_US.UTF-8 in /etc/environment as default localization.

Thanks to @Sofiya for the poorercputemp and Display Control packages that also have been added to desktop.

• Grub4Dos is now included in the System menu. Making KLV-Airedale capable of setting up a boot-able device using GParted and Grub4Dos.

• CUPS starting as a service has been added and is working thanks to @rcrsn51 spotting missing components!

This is constructed from KLV-Airedale-beta27->rc1->rc2 and is equipped with a Void Linux kernel version 6.0.12_1 SMP PREEMPT_DYNAMIC constructed with @wiak 's scripts that will extract the Void Linux kernel for KLV. Also has had a system wide upgrade. Uses an initrd.gz based on the FirstRib skeleton initrd.gz constructed by the kernel/module creation script. Firmware SFS is from a woof-CE kernel-kit built huge 6.0.0-1 kernel.

KLV-Airedale-rc3 is just as at home on FAT32, NTFS prtitions as it is running from ext2/3/4 formatted partitions.

Also included is wiak's generate a set of boot stanzas script. fredx181's mksplash has a menu entry and the remaster script is installed.

With the addition of a xfce4 desktop tiling configuration. A tip from wiak for configuring Tiling windows done with the Super (Windows) key and an up, down, left, right, home, pgup, pgdown or end key.

gxmessage in the default rootfs.

save2flash has been expanded to handle persistence on FAT32 and NTFS partitions.
The mksplash GUI utility to create splash notification banners.

The latest initrd.gz brings vFat and NTFS formatted partition support to KLV, allowing persistence on NTFS/vFat systems as well as the usual /ext2/ext3/ext4/swap support.

• included htop, Grub4Dos, CUPS

• created a symlink /root/spot with the target /home/spot

• Auto login cleaned up.

• includes also the logout logic provided by fredx181 gives true mulit-user support.

• replaced loop.cfg to the most recent modifications.

• Debian kernel 6.0.0-3-KLV SMP PREEMPT DYNAMIC is used.

• added gtkhash

Plus the other important improvements contributed by the KLV team.

Added @fredx181's save2flash utility that can be used when KLV is started in RAM2 mode to perform session saves on demand for persistence.
This is similar to PUPMODE13 in Puppy Linux.

fredx181's swap partition enable script includes the latest revisions and also added are the packages

• mime-add-1.0_0.noarch.xbps

• edit-sfs-1.0_0.noarch.xbps

KLV-Airedale-beta25 is able to load squash SFS packages on the fly or during the boot sequence.
Squash files and ISO images can be opened from the file manager and the read the contents.

• can run with rootfs, 01fimware and 00module SFS files as uncompressed directories.

• Also able to load compressed and/or decompressed directories,
  once a 2 digit prefix is added to the file name.

• It is possible to mix using compressed squash files and uncompressed directories.

Also can be downloaded from https://rockedge.org/kernels in ISO->Kennel_Linux->Airedale

[Sofiya]

It's time to set up Bluetooth
was used, Bluetooth adapter

helpful information: https://docs.voidlinux.org/config/services/index.html
https://docs.voidlinux.org/config/bluet ... stallation

1.install bluez , bluez-alsa , blueman
2.enable the service ln -s /etc/sv/bluetoothd /var/service , ln -s /etc/sv/dbus /var/service
3.include in the group usermod -G bluetooth -a <username> users ( root,spot,weedog )
4.Menu>Settings>Blooetuth adapters. ( bluetooth manager ).
5.save session
6.reboot

I have a wireless headset connected (Headphones), and the phone.
headset ( Headphones ), to output sound to headphones, you need to select the name of your headset in Pavucontrol

[wiak]

Yes, pretty much all the bells seem to be ringing in tune for our KLV-Airedale Christmas. Well done putting all the tricky bits together so quickly @rockedge!

[rockedge]

@wiak Still is Christmas Eve in Connecticut!

Should we add the cdrtools package that will supply mkisofs so this will be possible in KLV ?

Code: Select all

mkisofs -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -D -l -R -v -V "KLV-Airedale" -no-emul-boot -boot-load-size 4 -boot-info-table -o "KLV-Airedale-rc4.1.iso" KLV-Airedale-rc4
isohybrid KLV-Airedale-rc4.1.is

And of course look at @Sofiya 's Bluetooth configuration addition for a rc5 on New Year's Day perhaps...........

Overall size needs to be addressed. We have not really used strip on anything or limited the documentation. So far none of that type of optimizing has occurred. I do like having the docs though so this option will need to be thought about.

[dancytron]

Maybe put the docs in an sfs file that can be downloaded separately like the devx?

[rockedge]

@dancytron Now that you mentioned it, a possible devx type SFS would be very useful but might not work that well as far as any system updates would be concerned. There could be version conflicts between the rootfs, upper_changes and the devx. Some experimenting is going to be done next year (a few days away!!) to determine how to handle development tools added in. As it is now xbps-install -Sy base-devel cmake git
installs the needed packages and sets up a good Dev environment.

The docs as an SFS though is an interesting idea and will need to be tried out and tested. That KLV follows the Void Linux base fairly closely and also is a rolling release type OS, keeping the SFS current might be tricky. That will be determined as we give it a test run or two.

[wiak]

@dancytron Now that you mentioned it, a possible devx type SFS would be very useful but might not work that well as far as any system updates would be concerned. There could be version conflicts between the rootfs, upper_changes and the devx. Some experimenting is going to be done next year (a few days away!!) to determine how to handle development tools added in. As it is now xbps-install -Sy base-devel cmake git
installs the needed packages and sets up a good Dev environment.

The docs as an SFS though is an interesting idea and will need to be tried out and tested. That KLV follows the Void Linux base fairly closely and also is a rolling release type OS, keeping the SFS current might be tricky. That will be determined as we give it a test run or two.

Yes, I was also wondering about compiler and so on, be that via devx or just leave user to install. I think providing recipe to install is probably better than a devx because as you say, if the kernel gets changed so too does the devx, but the same issue applies to Puppy Linux so maybe a devx would be an acceptable alternative if you used a script to regenerate devx each time you provided any new release with different kernel. I'm not sure. I usually just install the component parts via package manager myself since the end-size of the installed distro is not important to me really.

As far as iso-write support is concerned, I tend to personally use xorriso, simply because that is what I became used to via DebianDogs - I presume/think DDs still use xorriso. Even then I don't really know xorriso usage well at all - I just guessed recently in attempt at using it with EFI support in KLA iso production. I understand you @rockedge use mkisofs (am I correct in my off-the-head belief that is different to xorriso?) and presumably have a reliable build KLV (including EFI) recipe that you use with that. Assuming no difference/advantage one way or the other, would be good to include that in the build along with buildscript, plugin, and your mkisofs recipe so others could easily rebuild. I realize the plugin probably not complete enough as yet to generate the final result, but I do know the git published KLV-Airedale f_plugin, I tested, provided a pretty good first attempt before some manual additions to polish things off.

In my KLV release, the supplied build plugin is complete and I did release it with build scripts and my (probably incorrect) xorriso command particularly to allow users to rebuild the root filesystem as an alternative upgrade mechanism (including new initrd generation FRmake_initrd script) - I would recommend including these components and gradually making everything rebuildable/upgradable in that way. In KLA I just put all the scripts I used for the build alongside all the frugal install components - but maybe best in their own folder since a bit confusing in terms of not indicating what is involved in booting the system. However, the reason I put them there was that it becomes immediately possible to run a build_firstrib_rootfs.sh script to make an up-to-date uncompressed new rootfilesystem - but a suitable README instructions file in a separate BUILD_SCRIPTS folder, along with the latest/most-current buildscripts, build_plugin, FRmake_initrd (2 scripts) and the likes of most current modify_initrd_gz(xz), (u)mount_chroot and so on scripts would probably be a better arrangement. I like including the build system used since tiny to include and hopefully would encourage new developers of the system - the more the Merry (Christmas). Of course each new release should use latest build system scripts when these are ever updated (which is pretty rare overall).

[rockedge]

@wiak That's another item still on the list. I do not know how KLV will react to EFI booting. I don't have any systems that have UEFI only BIOS. So I haven't been able to test what is there presently for EFI.

I agree about including the build scripts and utilities. Once we have a "production" release that ISO will include a directory with all the scripts within. I'll put rufwoof's save.sh and merge_changes.sh in with the rest of the scripts. I'll also include the latest PLUG for KLV construction to go along with the build scripts.

I may not include the cdrtools package but instead give a recipe to install it if needed, just like the base-devel package that has all the dev tools included.

[Clarity]

Just a note on cdrtools.

I clearly understand your post suggestion and it is a good one if not included. Yet, thinking a little, that apparent innocent step might not be one for this distro to be an OOTB for new and experienced users. Most users on this thread are comfortable in navigation with the traditional nature in features for ALL hardware devices built-in PCs up until very recent. ALL of my laptops have DVD units that come into play when attempting to debug ISO behaviors. I do not (like some others) have a laptop that does NOT have a DVD, but I am old with old stuff before recent 4 years when the lightweight laptop craze hit full stride.

Anyway, I like some of you use QEMU for various test. AND some use it by booting an ISO file versus an install image from time to time for how easy it is to launch into a distro test. When I encounter a problem with a ISO file booting, I have couple of test that I do in an effort to isolate whether the ISO issue is its software or its firmware. One of those confirmations I do when QEMU surfaces a problem in ISO use, is to make a REAL DVD from the ISO and test to see if the observation in QEMU matches bare-metal hardware use.

So, cdrtools & Pburn are useful facilities to, without thought, make this accomplishment simple.

SIMPLE in that I have come to rely on those in all current traditional PUPs/DOGs for all these older PCs lying around....when needed.

I am comfortable enough to navigate the change, but wonder other user impact that might surface, unwantedly.

Just a thought.

[Clarity]

This post has nothing to do with KLV ... rather an observation noticed earlier in couple older modern PUPs.

If the author chooses to NOT include a product while leaving direction (toast meassges) for the user to follow to add that product to the system. The messages are good, BUT, I personally think those kinds of messages 'could' not be a message, but instead, could offer to launch an installation of the product for user's to choose. So far, maybe for time related reasons, authors who do this may be overlooking this kind of help for the user who want the product.

This may be a simpler approach rather than spending time to craft what kind of response is to be given when an feature is removed while the icon for its use remains. It mainly says "Not present. click install button to add to the system or click cancel/exit button".

This is mentioned, today, as we are entering a new era in Puppyland where various distros have wildly different package-managers. Thus the steps to add a package, successfully, could be a struggle for the tire-kickers seeking an attractive and stable PUP...which KLV is.

I hope that other developers see this post for evaluation of what to do when any popular product requires additional steps when not included in their distro.

Hope this post is not short-sighted as this MAYBE a need for something in WoofCE builders that applications offering to launch installations would have as standard in all PUPs. Thus an message app offering install would have a simple universal PUP tool where its purpose is to know how to craft and launch, specific, to the distro's PM. This would eliminate sending the user to a PPM screen, rather, it would merely properly launch the installation for the missing product on behalf of the app.

[wiak]

If the author chooses to NOT include a product while leaving direction (toast messges) for the user to follow to add that product to the system. The messages are good, BUT, I personally think those kinds of messages 'could' not be a message, but instead, could offer to launch an installation of the product for user's to choose. So far, maybe for time related reasons, authors who do this may be overlooking this kind of help for the user who want the product.

Well that is certainly something to think about. As I see it (as an observation), one of several major differences between distros discussed/worked-on via this forum compared to mainstream distros (such as official Ubuntu) is that here an attempt is more often than not used to limit the download size (whatever media type is provided for download), whereas a mainstream distro tends to include everything including the kitchen sink. One approach to keeping distro download size low (the traditional Puppy approach) was to simply reduce OS features. For example making the distro single-user only, being root user, cut out man pages and other docs, and limit out-of-the-box internationalisation/languages, and to try and provide most expected application abilities via often limited/slimmed-down apps for the likes of spreadsheet, reading a doc file, a pdf or simple graphics editing. That plus the extra of the addition of extremely flexible layered filesystem handling (allowing easy addition of larger apps and so on via sfs addons). The approach has certainly been demonstrated as working well, though I think most Puppy users do tend to greatly expand the final size of their Puppy installations anyway, via the likes of sfs addons or AppImages and other mechanisms for adding full versions of major apps.

Nowadays, we don't necessarily try to provide all the functionality a user might want out of the box, but instead simply don't include some apps. The 'philosophy' for that situation is somewhat different from traditional Pups - the idea is that most users will not be satisfied with slimmed down, smaller, but less capable versions of applications, but rather want to expand their system to use the full version of apps (e.g. full inkscape rather than the very limited inkscape-lite, and provision of as light a webbrowser as possible just as a starter mechanism prior to download/install of a full browser, which most everyone wants in the end). But in the likes of KLV we tend not to tell the user what extra apps they may or may not want or any specific help in how to fetch and install them; the idea being that since a fully upstream-compatible package manager is provided it is relatively trivial to install any application a user might desire. Yes, some sort of Quick-install gui app could be provided - some pups have done things that way - but when the package management system is pretty much 100% reliable I wonder why that would be useful and especially since who are we to tell a user what they might need? I suppose I see the exception to my 'doubt' is for the case of someone wanting sfs portables, AppiImages and so on - a quick pup type helper GUI would be a bonus then. However, such entities as AppImages are often wanting to allow sharing them between distros we have installed so quick pup type way of installing doesn't really help for cases where AppImage, for example, has already been fetched and stored somewhere by another distro (such as Puppy) - we don't want ever to download the exact same AppImage for any new distro we are running when it is already in our storage somewhere - for any quickpup app install utility to work in such a scenario is if all the distros had an agreed convention such that they would check in say the same place to see if AppImage (and so on) already been fetched by another distro.

I suppose I am in two minds about such provision therefore; I certainly don't like the idea of providing an icon for an app that doesn't yet exist on the system, but I'm also aware that, as things stand, a user needs to open a browser and check the likes of Void Linux packages website to determine if a package even exists (though using GUI octoxbps tends to make finding packages from Void Linux repos really easy anyway). I suppose I'm not really a fan of providing too many inbuilt applications to a user in a distro release that has sufficiently good package management anyway; for example, we supply firefox when a user may want chromium (personally I always install chromium and never use firefox since I only need and want one fully capable browser - why would I want otherwise, and choice is a fine thing unless we prefer a Nanny state sort of scenario all set up and decided without our own preferences being relevant).

My overall personal view, therefore, is that a user is in charge of their own system, no matter how many distros they sometimes boot into. It becomes therefore their own responsibility to know what they have already downloaded (AppImages and so on) and nothing any auto-install program can reasonably be expected to know for them. Whilst some agreed convention management system for all distros installed would be a neat project, and could achieve some success I'm sure, I think such design is probably a non-starter in the reality of how independent all distro developments actually are.

[dancytron]

@dancytron Now that you mentioned it, a possible devx type SFS would be very useful but might not work that well as far as any system updates would be concerned. There could be version conflicts between the rootfs, upper_changes and the devx. Some experimenting is going to be done next year (a few days away!!) to determine how to handle development tools added in. As it is now xbps-install -Sy base-devel cmake git
installs the needed packages and sets up a good Dev environment.

The docs as an SFS though is an interesting idea and will need to be tried out and tested. That KLV follows the Void Linux base fairly closely and also is a rolling release type OS, keeping the SFS current might be tricky. That will be determined as we give it a test run or two.

I don't do a lot of compiling, but in DD I always generate a new devx file in apt2sfs when I do. Can't think of any other way to solve the update issue.

The docs.sfs has been an idea of mine for a while and I built one manually once. Separate .sfs for docs, new docs live with the rest of the updates, and then regenerate the updated docs.sfs file when you remaster. That all may be too much trouble for what it's worth though.

[rockedge]

I agree with @wiak that the main goal of KLV and KLA is to provide rock solid, very efficient distro's that are the strong foundation from which each user can build from. Every user has their preferences in what applications they use. Our goal is to provide the foundation and a stable way of adding applications and setting up system expansions. It would be best to limit the size of a stock KLV and keep the base ISO as small as possible. It's already at 755 mb and we're hoping to keep it under 800 mb.

[Clarity]

I agree with both or you: @wiak and @rockedge. AND, I am aware (I think you both know) of the packaging and offering we have throughout Puppyland and the common functionality provided across the board. I am happy with the common package efforts we get with PUPs and DOGs on this forum,.

What I posted in not a complaint, but an observation of couple instances I see where an icon exist in desk's Menu which when clicked alerts the user that THEY MUST install the application. This is the developer's intent to keep the ISO file small and they see value when this is done in their distro. My idea is that when this is done, instead of a mere alert, a screen appears with NOT ONLY the alert message, but a button that would allow the screen to launch the product's installation or allow user to cancel.

The idea presented will not increase a forum distro's size thus keeping with the author's ISO file concerns; rather it would accelerate the user to add the desired feature to the system by following the suggestion in the alert with buttons to complete app installation and launch.

Intent: Is to accelerate user acceptance of the author's distro as it becoming easier and easier to get comfortable and continue progress and use with a little less burden for needed subsystem features.

Again, that was a perception for a greater experience with little to no more author as the alert is the same with the alert screen could be something standard for any Menu item whose product is in the distro's REPO.

Thanks for what you share! ... AND Happy Holidays during this season to everyone.

By the way an example, although not a universal 'alert-install feature', is what some distro owners employ for adding Browsers where an icon is clicked the pop-up alert indicating a need to approval for installation of the missing subsystem item. Here, this approach reduces user knowledge to add the feature.

While an example of an 'alert' for a missing feature is some included Menu item for QEMU GUI where a mere alert is toasted to the desktop. That alert could, assuming the addition of some buttons extend the offer to install via a button click.

[wiak]

I would think a quick way to make a devx that wasn't noticed by xbps database would be to make current upper_changes temporarily into a rollback changes by giving it high 2digit filename, then, immediately after booting install the dev components wanted. The xbps database related to that will all be in that uncompressed upper_changes so easiest would be just to remove that xbps database section of that folder. Might be done all in RAM and thereafter the upper_changes written out as a numbered sfs which won't overwrite previous upper_changes xbps database. Of course the temp rollback uc just gets renamed then back to upper_changes again. The Debian dogs have some apt2sfs utilities, which I presume do something similar so worth looking into their technique but for Void xbps.

[wiak]

When new build made probably need to make new devx at same time especially for new appropriate kernel headers

[rockedge]

@wiak That is the exact method I intend to use to create a devx to start the experiment. Good idea I agree and there is flexibility to try various outfitting.

I also tried out installing cdrtools and created a working ISO of KLV with mkisofs and isohybrid in a QEMU virtual machine using KLV.

isohybrid I copied from F96

[wiak]

@wiak That is the exact method I intend to use to create a devx to start the experiment. Good idea I agree and there is flexibility to try various outfitting.

I also tried out installing cdrtools and created a working ISO of KLV with mkisofs and isohybrid in a QEMU virtual machine using KLV.

isohybrid I copied from F96

Could you publish any new make iso command lines you are using just now, including for isohybrid - these are final steps that can often not be used, but worth keeping a record of how we are doing things. You will find the xorriso commandline I used for KLA inside the iso root folder. I doubt my command is correct for EFI use, but maybe someone will correct me on that one day and also good to know how to do everything with cdrtools instead.

As far as devx is concerned, I must say I generally don't use that - just install the dev components via package management. However, some who compile very rarely probably prefer just to have that as an addon sfs though unless a user is choosing to run from RAM there isn't any great benefit in having that as an addon IMO; I just install it and it is always there, which is also a benefit when using KLA since Arch user repo AUR uses both git and often compiles prior to installing so that environment is best always present then.

[rockedge]

publish any new make iso command lines you are using just now, including for isohybrid - these are final steps that can often not be used, but worth keeping a record of how we are doing things.

These commands assume that the necessary boot components are in a /boot directory within the system root.

Screenshot(2).jpg (28.09 KiB) Viewed 3260 times

The basic commands to build an ISO which are done in a terminal one level above the directory to be compressed into an ISO :

Code: Select all

mkisofs -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -D -l -R -v -V "KLV-Airedale" -no-emul-boot -boot-load-size 4 -boot-info-table -o "KLV-Airedale-rc4.1.iso" KLV-Airedale-rc4
isohybrid KLV-Airedale-rc4.1.iso

If the boot components are not in a /boot directory but stacked in the system root than modify the command to reflect that:

Code: Select all

mkisofs -b isolinux.bin -c boot.cat -D -l -R -v -V "KLV-Airedale" -no-emul-boot -boot-load-size 4 -boot-info-table -o "KLV-Airedale-rc4.1.iso" KLV-Airedale-rc4
isohybrid KLV-Airedale-rc4.1.iso

[Sofiya]

Conky installation.
Looks like it's all set now
Conky is installed as well as "Conky-manager" to manage Conky.
"Conky-manager" not in OctoXBPS -
assembled ,also requires conky , imageMagick , 7zip , libgee08 to be installed. these packs out of the box

Conky-manager - https://drive.google.com/drive/folders/ ... share_link

also don't forget to set HDD,GPU,CPU temperature display
for this, install hddtemp , lm_sensors

[geo_c]

Quick question, where is the script for sclock located? I can't seem to find it. It appears to be based off of @MochiMoppel's clock script, but I'm just guessing about that.

[rockedge]

@geo_c sClock that is in KLV is compiled C code. Shared by a user just before he quit the forum not too long ago. This was developed alongside @MochiMoppel 's very nice scripts.

Here is the C program code:

Code: Select all

gcc sclock.c -o sclock $(pkg-config --cflags --libs gtk+-3.0)

Code: Select all

/* sclock.c */
/* Provided on https://forum.puppylinux.com/viewtopic.php?p=59787#p59787 */
/* by misco_2083 */
/* requires libgtk-3-dev on Debian, pulls in a lot of extra packages */
/* if you use it on antiX */
/* commented and adapted by Brian Masinick */

#include <stdio.h>
#include <time.h>
#include <gtk/gtk.h>

static gboolean
on_timeout (gpointer user_data)
{
  GtkLabel *label = GTK_LABEL (user_data);
  time_t timer;
  char buff[12];
  struct tm* tm_info;

  time (&timer);
  tm_info = localtime(&timer);

  strftime(buff, 12, "%r", tm_info);

  gchar *markup = g_strdup_printf ("<b><span font='Sans Bold 16' foreground='green'>%s</span></b>", buff); 
  gtk_label_set_markup (GTK_LABEL (label), markup);

  g_free (markup);

  return G_SOURCE_CONTINUE;
}

void destroy_handler (GtkApplication* app, gpointer data)
{
    g_application_quit(G_APPLICATION (data));
}

static gboolean
key_handler (GtkWidget *w, GdkEventKey *ev, gpointer data)
{
  GtkApplication *app = GTK_APPLICATION (data);
  switch (ev->keyval)
    {
    case GDK_KEY_Escape:
        destroy_handler(NULL, app);
        return TRUE;
    }
  return FALSE;
}

static gboolean
button_handler (GtkWidget *w, GdkEventButton *ev, gpointer data)
{
  if (ev->button == 1)
    {
      gtk_window_begin_move_drag(GTK_WINDOW(w),
          ev->button,
          ev->x_root,
          ev->y_root,
          ev->time);
      return TRUE;
    }
  if (ev->button == 3)
    {
      GtkApplication *app = GTK_APPLICATION (data);
      GtkWidget *item, *popup_menu;

      popup_menu = gtk_menu_new ();
      gtk_menu_set_reserve_toggle_size (GTK_MENU (popup_menu), FALSE);
      item = gtk_menu_item_new_with_label ("Exit");
      gtk_widget_show (item);
      gtk_menu_shell_append (GTK_MENU_SHELL (popup_menu), item);
      g_signal_connect (G_OBJECT (item), "activate", G_CALLBACK (destroy_handler), app);
      gtk_menu_popup_at_pointer (GTK_MENU (popup_menu), NULL);
      return TRUE;
    }
  return FALSE;
}

static void
activate (GtkApplication *app,
          gpointer        user_data)
{
  GtkWidget           *window;
  GtkWidget           *grid;
  GtkWidget           *label;
  GtkStyleProvider    *style_provider;
  char                *css_text;

  window = gtk_application_window_new (app);
  gtk_window_set_title (GTK_WINDOW (window), "Digital Clock");
  gtk_window_set_default_size (GTK_WINDOW (window), 220, 20);
  gtk_window_set_decorated (GTK_WINDOW (window), FALSE);
  gtk_window_set_skip_pager_hint (GTK_WINDOW (window), TRUE);
  gtk_window_set_skip_taskbar_hint (GTK_WINDOW (window), TRUE);

  grid = gtk_grid_new ();
  gtk_grid_set_column_homogeneous (GTK_GRID (grid),
                                TRUE);
  gtk_grid_set_row_homogeneous (GTK_GRID (grid),
                                FALSE);
  gtk_grid_set_row_spacing (GTK_GRID (grid), 10);

  label = gtk_label_new(NULL);
  g_timeout_add (1000, on_timeout, label);

  gtk_widget_set_halign (label, GTK_ALIGN_CENTER);

  gtk_grid_attach (GTK_GRID (grid), label, 0, 0, 1, 1);

  gtk_container_add (GTK_CONTAINER (window), grid);
  gtk_container_set_border_width (GTK_CONTAINER(window),5);

  style_provider = GTK_STYLE_PROVIDER (gtk_css_provider_new ());
  gtk_style_context_add_provider (gtk_widget_get_style_context (window),
                                  style_provider,
                                  GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);

  css_text = g_strdup_printf ("window,\n"
                              "window\n"
                              "{\n"
                              "  background: black;\n"
                              "}\n");

  gtk_css_provider_load_from_data (GTK_CSS_PROVIDER (style_provider),
                                   css_text, -1, NULL);
  g_free (css_text);

  g_signal_connect (G_OBJECT(window), "destroy",
                    G_CALLBACK (destroy_handler), app);
  g_signal_connect (G_OBJECT (window), "key-press-event",
                    G_CALLBACK (key_handler), app);
  g_signal_connect (G_OBJECT (window), "button-press-event",
                    G_CALLBACK (button_handler), app);
  gtk_widget_show_all (window);
}

int
main (int argc,
      char **argv)
{
  GtkApplication *app;
  int status;

  app = gtk_application_new ("org.gtk.simple_time",
                             G_APPLICATION_FLAGS_NONE);
  g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
  status = g_application_run (G_APPLICATION (app), argc, argv);
  g_object_unref (app);

  return status;
}

 
}

[geo_c]

@geo_c sClock that is in KLV is compiled C code. Shared by a user just before he quit the forum not too long ago. This was developed alongside @MochiMoppel 's very nice scripts.

Nice, but way over my head. Is there a way to configure the color or size without recompiling?

My clock comes up red on boot, but if I restart the clock, it comes up orange. Not a big deal, but I'm a color tweaker, so it's always nice to know.

The other feature the mochi clock has, being a window, it can be set to stay above other windows, etc.

[rockedge]

@geo_c take a look at how the .desktop file starts sClock. Try in a terminal:

Code: Select all

./sClock --font=18 --color=lightgreen

Code: Select all

[Desktop Entry]
Encoding=UTF-8
Name=sClock
Icon=/usr/local/jwmdesk/icons/jwmdesk64.png
Comment=Desktop Clock
Exec=sclock --color=orange
Terminal=false
Type=Application
Categories=X-Desktop
GenericName=Desktop clock

[rockedge]

@geo_c Try this

Code: Select all

./sClock --font=18 --color=lightgreen --keep-above --stick

[geo_c]

@geo_c Try this

Code: Select all

./sClock --help
./sClock --font=18 --color=lightgreen --keep-above

I was wondering if it had help for the options. I'm not in KLV so I couldn't check quickly. I'm good to go now. Thanks!

[rockedge]

@geo_c Try this one:

Code: Select all

./sClock --font=18 --color=lightgreen --keep-above --stick

Code: Select all

./sClock --help
Usage:
  sClock [OPTION?]

Help Options:
  -h, --help               Show help options

Application Options:
  --bgcolor=COLOR          Specify window background color, black, #000, rgb(r,g,b), rgba(r,g,b,a)
  --border=COLOR           Draw window border, same as bgcolor
  --border-color=COLOR     Set border color
  --center                 Place window at the center of the screen
  --color=COLOR            Specify color of the label, white, #FFFFFF
  --date=STRING            Specify display time, e.g. %a %b %d/%m/%Y %H:%M:%S but not 'now
  --font=FONT              Specify font to use
  --keep-above             Keep window above, default is to keep window below
  --lock                   Lock position
  --opacity=INT            Set window opacity, compositing must be enabled first
  --posx=INT               Specify X position to use
  --posy=INT               Specify Y position to use
  --stick                  Show window on all desktops

[wiak]

Just I think beating Clarity to it. I just tried a new install of SG2D with rc4.1 in BOOTISOS folder and it booted fine, and I was using w_changes=RAM2 (like Pupmode 13) and that worked fine with save2flash save persistence.

Note however, on my newish HP machine, which now has Secure Boot turned off, current SG2D that worked was this one called (after unzip) "classic":

supergrub2-classic-2.06s2-beta1-multiarch-USB.img

The secure boot capable one didn't find the iso on my secure boot disabled machine (maybe would is I had the puppy.cer registered to the UEFI bios - I don't know, I didn't try the combination (and noted the SG2D creator's comment that it was experimental and for Debian/Ubuntu by default):

A new beta release which adds SecureBoot support to Super Grub2 Disk. For now Ubuntu (x64) and Debian (ia32 and x64) are only supported, although you can boot into another Distro’s shim (if it’s signed by ‘Microsoft Corporation UEFI CA 2011’)

Note also that since FirstRib initrd based distros always uses a save folder name of upper_changes (assuming Linux partition format), you cannot put two or more FirstRib isos in same BOOTISO folder and get w_changes=RAM2 mode to still work (since they would share the same upper_changes folder, which would be a mess...). There is way to arrange things though if you want many FR-based distros in their: put the isos in their own different-named subdirectories inside BOOTISOS, but make a symlink in BOOTISOS itself that is simply the exact name of the iso (including extension) that points to the actual iso inside the subdirectory). A bit tricky, but trivial to arrange really. Keeping a common upper_changes save folder name makes a lot of other functionality easier to arrange in the initrd so I have no plans to change that.

Why am I looking at SGD2? Partly to check KLV still works with it, but also because I have a few ideas I want to try out in my FR initrd to try and make some of the other flexible layering arrangements able to be accommodated even when booting from ISO using SGD2 or the what I find even trickier 'Ventoy'; the idea in my mind may not come to anything so if I say no more about it later then it was too complex for my tastes or simply didn't work. But at least we know SG2D works pretty well with KLV and even with that all important w_changes=RAM2 simplest case scenario without having to stop or edit the SG2D boot menu (for more complex KLV scenarios you would still need to halt the boot process and edit the kernel line parameters, but not if okay having upper_changes in BOOTISOS folder where the isos are held).

[Clarity]

... in same BOOTISO folder and get w_changes=RAM2 ...

Assume you have

• a linux partition names Persistence AND you have a folder Sessions where you want all of your KLV persistence to land

Should it be advised to save "w_changes=" to that disk label versus allowing it to default to the BOOTISOS folder? Thus a boot-time edit of the boot stanza's line to 'direct' the boot process of where to find its 'persistence'.

ON another note when a new PUPPY is booted and it finds old persistence for a prior version, the user will be offered the option to upgrade the old persistence for use with the new. Although I haven't tested this in KLV, can I assume it, too, offers similar upgrades when booting a new version and it find the old session? (THIS IS NOT a request to make KLV behave in Puppy fashion, merely a request of current behavior)

[dancytron]

If anyone else doesn't like the xfce animations, especially the collapsing scrollbars.

Add the following line to /etc/environment

GTK_OVERLAY_SCROLLING=0

That's doesn't get rid of it in Firefox.

Per https://connect.mozilla.org/t5/discussi ... /td-p/5433

Go into "about:config", search for "scroll", and make these changes:
1. Change "widget.gtk.overlay-scrollbars.enabled" from "true" to "false".
2. Change "widget.non-native-theme.gtk.scrollbar.thumb-size" from "0.75" to "1.0".
3. Change "widget.non-native-theme.scrollbar.size.override" from "0" to "15".
That will give you wider scrollbars that stay wide even when your mouse is nowhere near them.

I also turned the compositor off.

I'm using it for TV viewing today.

Dan