Core v16.0beta1

[Juanito]

Team Tiny Core is pleased to announce that Tiny Core 16.0 Beta1 is available for public testing:

http://repo.tinycorelinux.net/16.x/x86/release_candidates/distribution_files
http://repo.tinycorelinux.net/16.x/x86_64/release_candidates/distribution_files

This is an beta level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.

We appreciate testing and feedback.

Changelog for 16.0 alpha1:
* kernel updated to 6.12.11
* glibc updated to 2.40
* gcc updated to 14.2.0
* binutils updated to 2.43.1
* e2fsprogs base libs/apps updated to 1.47.1
* util-linux base libs/apps updated to 2.40.2
* zlib base lib updated to 1.3.1

* getTime.sh: support more than one server from dhcp from miesi-ionos
* update-everything: offer to remove deprecated extensions from bdantas
* tc-function remove mount/umount from bb list from CardealRusso
* provides.sh: Rich's improved versions: update from CardealRusso
* linuxrc: remove symlink from GNUser
* update-everything: backup stale .dep files form bdantas

Not in the base, but also updated:
* mirrorpicker: grab info.lst from 15.x
* mirrorpicker: explicitly use bb wget
* editor: various changes from Rich

Note also that the fltk_projects in x86_64 have been updated to use fltk-1.4 with x11 and wayland. In the interests of minimising bloat the x86 fltk_projects remain with fltk-1.3 x11 only.

[MikeLockmoore]

I've updated to the RC release.  The attached screenshot is with my current build of FLWM_topside.  The window management buttons are on the left rather than right because the new fractional scaling of FLTK 1.4 is tricky to implement for the frame (window "decoration") because the X11 functions deal in coordinates with in real pixel values whereas FLTK mostly works in it's scaled coordinates (which works great for the application window contents, but is tricky for placing elements relative to the border).  The titlebar characters are scaled up in a way that is proportional to the FLTK fractional scaling factor, which the FLTK library will determine from the Xdefaults Xft.dpi setting (probably the preferred way, since it works with other WMs) or an explicit FLTK_SCALING_FACTOR environment variable, if defined.  I'm not certain the title is scaled exactly right.  I'll get an image viewer that lets me count pixels more easily and work that out.

Even if this window button placement is OK, there's several other issues with my custom build of FLWM I've noticed:
1) The pop-up menu is missing the sub-menus for applications and system commands ... this is probably just a temporary issue in my custom build! 
2) The window resizing method of dragging on the window border only works on the top edge (to change height) and upper left corner (height and width).  This is not very workable due to the next issue...
3) Windows that are large are often placed where their titlebar and left edge is just off-screen, so I cannot grab the resize corner
4) Mouse cursor jumps to odd locations sometimes

I will try the standard RC build of FLWM in a few minutes. Maybe it is mostly OK and the full release of TC 16 can just go with that.

[MikeLockmoore]

Update with the standard RC build of flwm...
1) is not an issue, the popup menu has all three submenus  (Applications, OnDemand, SystemTools); I'll need to sort that out in my custom build 
2) same challenges to window resizing exist... it would be much nicer for all users to be able to resize from any edge or corner, I'd say
3) does not seem to be an issue
4) have not noticed, but I have not tested very long

HOWEVER, if one sets up the fractional scaling in .Xdefaults  with Xft.dpi set to something much above 96.0 (e.g. 128.0 for 133%, or 144.0 for 150% scaling, the 'iconize' button will disappear that should be placed in the lower left corner of the standard FLWM window frames with the titlebar on left.  I think this is fundamentally the same issue I was having with the 'topside' button placement... the scaled coordinate is too big to be visible in the clipping rectangle's pixel coordinates. Basically, the button placement code needs to un-do the default fractional scaling of the FLTK library when positioning buttons at the limits of the window to the right and/or bottom.
Note: this iconize button disappearing issue does not occur if one sets the .Xdefaults value of Xft.dpi to 96.0 (100%) and then manually scales up any specific window with the scaling hotkey (Ctrl + Shift + EqualsKey (i.e. a Plus), or if your FLTK prefs have SimpleZoomShortcut set to 1, you can just use Ctrl + EqualsKey ).

[Rich]

Hi MikeLockmoore

... 2) same challenges to window resizing exist... it would be much nicer for all users to be able to resize from any edge or corner ...

As long as I can remember, FLWM_topside allowed resizing from
the top, right, and bottom edges as well as all 4 corners. The
left edge was never an option, which is fine by me.

... if one sets up the fractional scaling in .Xdefaults  with Xft.dpi set to something ...

Since FLTK provides user controlled scaling, one should not interfere
with it (in my opinion) by messing with the systems DPI setting.

[MikeLockmoore]

... if one sets up the fractional scaling in .Xdefaults  with Xft.dpi set to something ...

Since FLTK provides user controlled scaling, one should not interfere
with it (in my opinion) by messing with the systems DPI setting.

If you look in the FLTK documentation, it uses this setting to define the initial scaling factor:

Display Scaling Factor

FLTK uses the value of the Xft.dpi resource divided by 96. to initialize the display scaling factor. That is also what is done by the gnome and KDE desktops.

Users who want the apps scaled consistently and don't want to manually adjust every application should be able to set this value and the WM handle it in a reasonable way, IMO.  I don't think it is rocket science to fix this... I just need to understand what is scaled versus what remains unscaled, then make it all fit together correctly.

[MikeLockmoore]

Getting closer to the non-scaled version while supporting Xft.dpi setting.  At this DPI setting, the titlebar window management buttons are getting clipped a bit, and the size of the button is not leaving much room in very narrow windows for the app title (eg. MountTool).  I'll work on this some more in coming days. I think I could be over-scaling the titlebar font, which is also making the buttons bigger than needed.  --Mike

UPDATE: Definitely making the title font too big.  In the screenshot, the normal app menu font is 16 pixels high, but the title is 19 pixels high.  This was with a dpi setting of 144.0 (144/96 = 1.5, so 150% of normal scaling).

Another minor issue observed: in the wbar, causing the rightmost icon to zoom with the mouse-over motion leaves a small amount of background visual noise, maybe 8 pixels high by several pixels wide (it moves around a bit for me).  Not sure if I can catch in a screenshot.  I think this was happening with the dpi setting of 144 (for the above test).

[Rich]

Hi MikeLockmoore

... Not sure if I can catch in a screenshot.  I think this was happening with the dpi setting of 144 (for the above test).

Open a terminal and type:

Code: [Select]

screenshot.shthen move the mouse cursor over the wbar. When you see the
"background visual noise", hit the enter key. Since the terminal
still has focus, you should get a screenshot.

[Leee]

This isn't really specific to the version 16 beta but, since the fltk applets are in the discussion..

I've always found it inconvenient that when I open "apps" and I want to see the list of extensions in the repo (which is the only reason i open "apps"), I have to click the "Apps" button, slide down to the resulting menu, keep the mouse pointer on "Cloud (Remote)" while sliding over to the submenu then select and click on "Browse".  This is cumbersome using a mouse and even more so using a touchpad.

I know other people's use cases might be different, but I almost never open the apps utility that i don't want to see that list of extensions in the repo and I never use any repo other than the default.

Would it be possible (or even desirable to other users) to have a browse button on the main apps screen?  Or even maybe just move "browse" to the first menu under the "Apps" button?  Or just have apps get the list of extensions on startup?

[curaga]

As it also does ondemand and onboot management, which may be used offline, automatically fetching would be inconvenient to some users. Menu reorg, not opposed.

[Rich]

Hi curaga
Menu reorganization looks straight forward. Maybe something like:

Code: [Select]

Browse
Mirror Options  -----> Select Mirror
                  |
                  ---> Select fastest mirror
Load App Locally
Maintenance          >
Installation Options >
Quit

[Leee]

Thanks guys.  I figured the auto fetching would not be the best - only mentioned it because I thought it might be the simplest code change.

[Rich]

Hi Leee
How about this:

[Leee]

Big thumbs up on that.  I think that will make it much smoother, especially when using a touchpad (which I try not to do but too often end up doing anyway).

[MikeLockmoore]

I wanted to let people know that I've made some nice progress at making the FLWM work better with the fractional scaling (High DPI) functionality of FLTK 1.4, especially if a user configures a non-100% scaling parameter of Xft.dpi in the .Xdefaults configuration file.   Here's a screenshot of my current build of FLWM with the Xft.dpi set to 128.0 (which is 133% bigger than default).  If you don't want to take advantage of the fractional scaling for the window frames, you can leave Xft.dpi set at 96.0.  Whether you scale the frame with Xft.dpi or not, you can still dynamically resize your window contents anytime you want with a hotkey or environment variable as documented earlier.

I've added some smartness to the window management buttons in the frame so that when the frame gets too small for the window title and all of the buttons to fit, one or more of the buttons can be hidden, and if the window gets really small, the title will be clipped.

Thanks to a good suggestion from the FLTK developer Google Group, I was able to resolve the issues with bad window resizing and lack of ability to grab the window frame on all sizes for resizing.

The attached picture is the classic left-side titlebars, but the "topside" version has the same updates.

Unfortunately, not all is well yet... I don't have the main pop-up menu (that you get by clicking on the desktop background) working properly.  Will post again when I have that sorted (hopefully this weekend yet).
 

[Rich]

Hi MikeLockmoore
Looks good.