Carbon Bugs

greenjeans · 2025-11-08 03:52:39

johnraff wrote:

^I'm talking about the splash screen that the installer displays, which as you know has a size limit. ("grub-pc" is a bit bigger than syslinux at 800x600.)
We ship a grub boot image for the installed system which is 1024x765.
I'm pretty sure grub was unable to show anything bigger than that in the past, but you say it will now accept a fullsized wallpaper?
EDIT I found this: https://shallowsky.com/blog/linux/grub-splashimage.html
Use 640x480 at least initially. I think it's supposed to be possible to use other resolutions, but I haven't explored that yet. (Update: in 2025 I have successfully used a 1920 x 1200 image either as PNG or JPEG.)

^^Yep, been using a 1920x1200 in testing for a while now, I think you could go even larger if you like. The extra res is nice on desktop machines with larger monitors, and looks nice and sharp on laptops. I don't know when that changed but it looks nice and doesn't cost a lot in extra space.

Last edited by greenjeans (2025-11-08 04:26:04)

micko01 · 2025-11-08 04:51:03

On a different subject xwwall had some small bugs that are now fixed at github, xwwall-debian is updated too.

micko01 · 2025-11-08 05:03:58

Here's a tweaked sage 1024x768. I tweaked the logo marginally, and it may be a tiny bit crisper.

johnraff · 2025-11-08 06:00:07

OK in order:

greenjeans wrote:

been using a 1920x1200 in testing for a while now

I thought "why not also throw in a 1920x1200 for those who want it?" and fired up Gimp to scale the sage image. Unfortunately it's a different aspect ratio - wider - and would mean a Graphics Guy deciding how to crop or stretch the existing image, so let's leave it for now.

micko01 wrote:

xwwall had some small bugs that are now fixed at github, xwwall-debian is updated too

Thanks! I'll get the updated package built and uploaded today.

EDIT: I see that bunsenlabs xwwall and xwwall-debian have only "main" not "carbon" branches. My local fork's branch is "carbon" though, so I guess you renamed the branches to "main" at some point? Considering noone outside BL is likely to want "carbon" in their changelog, maybe you'd consider putting the bunsen-specific stuff in a carbon branch, at least for xwwall-debian?

Also, xwwall-debian on BL is ahead of the Micko repo, while BL xwwall is behind the Micko repo.

I'll wait till it settles down before building/uploading.

micko01 wrote:

Here's a tweaked sage 1024x768

Thanks for that too. Agree that the logo is a bit clearer.
Also noticed that the background is slightly squeezed horizontally (intentional?) and the filesize is slightly down.

micko01 · 2025-11-08 07:49:37

^ with xwall-debian I'll delete it on my github. AFAIK there was only the main branch on on BL github. Anyway that is moot really as far as a build is concerned. The only change was running dch to update the changelog. There was no carbon branch on 01micko/xwall-debian or my local copy.

--

Synced bunsenlabs/xwwall with 01micko/xwwall so should be good to go.

Details

johnraff · 2025-11-09 07:20:41

^No, indeed the "carbon" branch was a local one I added to do the packaging on so I could leave the upstream commit history clean. Sorry about the noise there.

Anyway, the new xwwall is safely up in the package repository now.

Last time I built it by copying out the contents of the debian/ directory in xwwall-debian, pasting it into xwwall carbon branch, committing the change: "Update debian/ directory from xwwall-debian package" and building. That works fine but felt a bit dirty somehow.

Did some research, learned about git submodules and worktrees, pulled xwwall-debian into a submodule of xwwall, "packaging" branch, put that branch in a separate worktree so the submodule directory wouldn't interfere with the upstream code when checking out "main". Now you can fetch the debian contents and merge it with xwwall and all the history is intact, while the upstream commits are in a separate "upstream" branch. OK looks good, but didn't build because of the extra xwwall-debian directory in the source.

Had to rename the submodule's directory .xwwall-debian so it was ignored - then it built. (Also needed a symlink from .xwwall-debian/debian to debian in the source root.)

Anyone interested in the details, I listed up the commands so I wouldn't have to spend 3~4 hours searching the internet next time I had to do something like this:

If debian packaging is in a different git repo from the app itself,
put it in a submodule, and move that to a new worktree to keep the packaging
from dirtying the upstream code:
(on software repo, "main" branch)

git checkout -b packaging
git submodule add git@github.com:BunsenLabs/xwwall-debian.git .xwwall-debian
git commit -m 'Add debian submodule from git@github.com:BunsenLabs/xwwall-debian.git in hidden directory .xwwall-debian'
ln -s .xwwall-debian/debian debian
(because debian/ is a subfolder, not root of xwwall-debian)
git commit -m 'add symlink "debian" to .xwwall-debian/debian/ '
git submodule set-branch --branch packaging -- xwwall-debian
git commit -m 'set xwwall-debian submodule to packaging branch'
git worktree add ../xwwall-packaging packaging
(now "packaging" branch is inside ../xwwall-packaging and
submodule contents are in ./xwwall-debian on "packaging" branch)
cd .xwwall-debian
git fetch origin
(refresh upstream data)
git checkout -b upstream origin/main
git checkout main
git merge upstream

Now "packaging" branch is in its own worktree "xwwall-packaging",
xwwall-debian submodule:
    packaging work and commits in "main"
    clean upstream history in "upstream".

"xwwall-packaging" is still linked to the base "xwwall" repo.
"main" branch only available in xwwall
"packaging" branch only in xwwall-packaging
NB: but don't forget the submodule in .xwwall-debian/ also has its own "main" branch.

Do 'git pull' in main "xwwall" repo to update software.

To update debianization,
in xwwall-packaging directory:
    'git merge main' to pull software upgrades from the separated-off xwwall's "main" branch
    'cd .xwwall-debian' (now in submodule)
    'git checkout upstream'
    'git pull'
    'git checkout main' (submodule's main)
    'git merge upstream'
    cd ../ (back in parent repo's "packaging" branch)

Now can do package build in  xwwall-packaging/

Maybe there's an easier way to do this...

Last edited by johnraff (2025-11-10 06:27:53)

micko01 · 2025-11-09 08:50:41

^Nice!

Maybe there's an easier way to do this...

Maybe, but some clever scripting could make it less cumbersome.

johnraff · 2025-11-10 06:44:18

micko01 wrote:

Maybe there's an easier way to do this...
Maybe, but some clever scripting could make it less cumbersome.

In fact only the last few commands would need to be scripted, so it wouldn't be that hard:

cd xwwall
git branch
echo 'only "main" branch is available here
"packaging" branch is in ../xwwall-packaging'
git pull
cd ../xwwall-packaging
echo 'only the "packaging" branch is available here'
echo 'pulling in any software upgrades from the separated-off xwwall "main" branch...'
git merge main
cd .xwwall-debian
echo 'Now in xwwall-debian submodule'
git checkout upstream
git pull
git checkout main
git merge upstream
cd ../
echo 'now back in xwwall-packaging "packaging" branch'
echo "now you can build the package"

It would be good to add some error-checking...

And I suppose the whole git repo setup process could be scripted too.

unklar · 2025-11-18 07:51:38

^@johnraff, have you seen this bug? (1920x1080)
https://forums.bunsenlabs.org/viewtopic … 05#p146705

Last edited by unklar (2025-11-18 08:01:03)

johnraff · 2025-11-18 08:05:15

^Sorry I overlooked the upper part of that post .
I have to close down now, but I'll have a look soon. Thank you!

johnraff · 2025-11-19 04:21:30

unklar wrote:

I just installed the alpha on my wife's new Linux ASUS Vivobook.
The USER opens a system file with Geany (e.g., fstab). Then, “Open with root” is selected in the menu. After entering the root password, Geany is “superimposed” over the USER's Geany. There is no color difference(!). Only moving it with the mouse reveals the risk of root editing.

Yes, a new - USER permissions - text editor window opens right on top, with a temporary copy of the file to be edited. When closed, changes to the file will be written as root to the original file, and the temorary file removed.

This is the sudoedit work flow, which we introduced to replace pkexec for text files.

Previous discussions:
https://forums.bunsenlabs.org/viewtopic … 01#p143401 ("Editing text files as root" section)
https://forums.bunsenlabs.org/viewtopic … 42#p144442
https://forums.bunsenlabs.org/viewtopic … 417#p67417

But I was wondering what the user reaction to this change would be.
*) The sudoedit way is safer because no GUI app's code is run as root, only a system command to write a file.
*) But the pkexec way brings up a text editor window which is visually different - at least with geany - so USER is well aware they are working as root. I think this is more comfortable for most people.

The pkexec configuration for bl-text-editor is still present in Carbon, so it would be quite easy to go back to that if most of the community preferred it.

unklar · 2025-11-19 10:14:42

^Thank you for taking the trouble.

My thought was that there should be a better color distinction.
I'm probably wrong about using a different editor.

e.g.

user - root better user - root

johnraff · 2025-11-20 00:58:43

^yes I quite agree that it's better for usability to have a root window styled differently from a user-owned window.

But the thing with sudoedit is that the text editor is not owned by root - it's a regular user-owned process and so gets the regular user styling. The only root process is when the edited temporary file gets copied to the system file.

Right now I don't know if there's any way to use a different style for the text editor when it's being run by sudoedit, as it's still a user process.

EDIT: It might be possible though... perhaps setting an environment variable... I'll have another look at it.

The other annoyance with sudoedit is that the file name gets presented as some random number, because it's just a temporary file.

Please see those previous discussions for a bit more on this topic.

Anyway, as I said, going back to pkexec is not out of the question...

Last edited by johnraff (2025-11-20 01:22:31)

johnraff · 2025-11-20 05:31:06

johnraff wrote:

I quite agree that it's better for usability to have a root window styled differently from a user-owned window.
...
Right now I don't know if there's any way to use a different style for the text editor when it's being run by sudoedit, as it's still a user process.
EDIT: It might be possible though... perhaps setting an environment variable... I'll have another look at it.

@unklar, how about this workaround?
Open (as root) /usr/bin/sudoedit.wrapper and add this line near the top (eg just after 'export SUDO_ASKPASS...'):

export GTK_THEME="Adwaita"

Now the text editor will come up white, in the GTK Adwaita theme that root usually gets.
A slight irritation is that the password entry box is also styled Adwaita.

unklar · 2025-11-20 09:40:39

^the content of the window itself would maintain the user's theme.
That should be enough to get the attention you need.

johnraff · 2025-11-20 09:58:02

unklar wrote:

the content of the window itself would maintain the user's theme.

I'm not sure whether or not the GTK theme should affect the actual window content - isn't that under the control of the editor?

But anyway, as you say it should be enough to get the user's attention.

greenjeans · 2025-11-20 14:51:46

johnraff wrote:

unklar wrote:
the content of the window itself would maintain the user's theme.
I'm not sure whether or not the GTK theme should affect the actual window content - isn't that under the control of the editor?
But anyway, as you say it should be enough to get the user's attention.

I don't know about geany, but in pluma the interior style is not set by the gtk theme, it's controlled by whatever "style" config you set in the gui itself, and those files are kept in /usr/share/gtksourceview-4/styles. I use the "classic" theme in mine but I modded it a fair bit to be more inline with my gtk theme. Of course that's a global setting so root looks the same. Don't know if that's helpful or not but thought i'd share the info. If geany does something similar, perhaps you can plugin a custom interior theme with your wrapper or exec command?

Last edited by greenjeans (2025-11-20 15:04:25)

marens · 2025-11-20 15:46:20

I don't know about Geany, but Gedit has the option to change the Color Scheme in Preferences.
I have many themes in ~/.local/share/gedit/styles.

I recently had to modify an existing theme (style) to make the background visible in screenshots (postimages).

Before:
https://postimg.cc/Yvk7FSNz

After:
https://postimg.cc/xXGHYHQq

#261 2025-11-08 03:52:39

Re: Carbon Bugs

#262 2025-11-08 04:51:03

Re: Carbon Bugs

#263 2025-11-08 05:03:58

Re: Carbon Bugs

#264 2025-11-08 06:00:07

Re: Carbon Bugs

#265 2025-11-08 07:49:37

Re: Carbon Bugs

#266 2025-11-09 07:20:41

Re: Carbon Bugs

#267 2025-11-09 08:50:41

Re: Carbon Bugs

#268 2025-11-10 06:44:18

Re: Carbon Bugs

#269 2025-11-18 07:51:38

Re: Carbon Bugs

#270 2025-11-18 08:05:15

Re: Carbon Bugs

#271 2025-11-19 04:21:30

Re: Carbon Bugs

#272 2025-11-19 10:14:42

Re: Carbon Bugs

#273 2025-11-20 00:58:43

Re: Carbon Bugs

#274 2025-11-20 05:31:06

Re: Carbon Bugs

#275 2025-11-20 09:40:39

Re: Carbon Bugs

#276 2025-11-20 09:58:02

Re: Carbon Bugs

#277 2025-11-20 14:51:46

Re: Carbon Bugs

#278 2025-11-20 15:46:20

Re: Carbon Bugs

Board footer