Tiny Core Base > Release Candidate Testing
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
--- Quote from: MikeLockmoore on March 03, 2025, 09:46:46 AM --- ... 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 ...
--- End quote ---
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.
--- Quote --- ... if one sets up the fractional scaling in .Xdefaults with Xft.dpi set to something ...
--- End quote ---
Since FLTK provides user controlled scaling, one should not interfere
with it (in my opinion) by messing with the systems DPI setting.
MikeLockmoore:
--- Quote from: Rich on March 03, 2025, 10:07:57 AM ---
--- Quote --- ... if one sets up the fractional scaling in .Xdefaults with Xft.dpi set to something ...
--- End quote ---
Since FLTK provides user controlled scaling, one should not interfere
with it (in my opinion) by messing with the systems DPI setting.
--- End quote ---
If you look in the FLTK documentation, it uses this setting to define the initial scaling factor:
--- Quote --- 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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version