BunsenLabs-wayland repository - in development

unklar · 2024-06-29 15:17:30

color-picker

micko01 · 2024-06-30 00:36:20

hhh wrote:

@micko01, I get an error with your script...
sh pick.sh
pick.sh: 36: export: Illegal option -f
... but maybe I'm not understanding how to use it. Where's the call to hyprpicker?

pick.sh: 36: export: Illegal option -f

should be

bash pick.sh coz export -f is a bashism.

$(hyperpicker) is the arg to the function (last line) - runs in subshell.

Any way the next version fully supports zenity (if installed) and falls back to yad. Also pops gtk4 color or gtk3 color dialogs respectively on button press; and since usermerge we all probably should be using #!/usr/bin/env bash instead of #!/bin/bash. Most, not all, errors warnings are suppressed now.

#!/usr/bin/env bash

find_color() {
    printf "%d" "0x${1}"
}

_get() {
    col_in="$1"
    if ! type zenity >/dev/null 2>&1; then
      echo -e '<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"  height="48px" width="48px" viewBox="0 0 48 48">
  <path d="m 0 0 48 0 0 48 -48 0 z" style="fill:'$col_in';stroke:none;"/>
</svg>' > $TEMPDIR/col.svg
    fi
    BCOL=${col_in/\#/}
    BR=${BCOL:0:2}; BG=${BCOL:2:2}; BB=${BCOL:4:2};
    BHR=$(find_color $BR)
    BHG=$(find_color $BG)
    BHB=$(find_color $BB)
    ZC='rgb('$BHR','$BHG','$BHB')'
    BHR=$(dc -e'3k '$BHR' 255 / p')
    BHG=$(dc -e'3k '$BHG' 255 / p')
    BHB=$(dc -e'3k '$BHB' 255 / p')
    X=''
    [ ${BHR:0:1} = '.' ] && X=0
    [ ${BHG:0:1} = '.' ] && X=0
    [ ${BHB:0:1} = '.' ] && X=0
    ZF=''$X$BHR' '$X$BHG' '$X$BHB''
    if type zenity >/dev/null 2>&1; then
      out=$(zenity --title="Color Picker" --icon="select-color" --list  --editable --print-column=2 \
      --text=" Copy and paste color found\n to your application:" \
      --column="Color Space" --column="Color" \
     "Color Hex" "$col_in" \
     "Color RGB" "$ZC" \
     "Color sRGB" "$ZF" \
     --ok-label="Color")
    case "$out"  in
       '#'*|rgb*)zenity --title="Color Picker" --color-selection --color="$out" >/dev/null 2>&1;;
       ?*)zenity --info --title="Info" --text="Only Hex or rgb() is supported to show the Color dialog" >/dev/null 2>&1;;
       '');;
    esac   
    else
      yad --title="Color Picker" --name="select-color" --form \
      --image="$TEMPDIR/col.svg" --text=" Copy and paste color found\n to your application:" \
      --field="Color Hex" "$col_in" \
      --field="Color RGB" "$ZC" \
      --field="Color sRGB" "$ZF" \
      --button="Color!select-color":'sh -c "yad --color --init-color='$col_in'" >/dev/null 2>&1' \
      --button="Ok!gtk-ok":0 >/dev/null 2>&1
    fi 
    return 0
}

export -f find_color _get

if ! type zenity >/dev/null 2>&1; then
    export TEMPDIR
    TEMPDIR=$(mktemp -d /tmp/colpickXXXX)
fi

# cleanup
trap "rm -rf $TEMPDIR" EXIT

_get $(hyprpicker)

zenity

return gui

color gui

yad

return gui

color gui

Edited to add yad.

Last edited by micko01 (2024-06-30 01:05:39)

micko01 · 2024-06-30 00:40:00

BTW - GTK4 sucks! The developers hate theming apparently so only choices are adwaita light or dark.

add this to /etc/environment for dark (might need a reboot)

export GTK_THEME=Adwaita:dark

johnraff · 2024-06-30 02:42:51

micko01 wrote:

...since usermerge we all probably should be using #!/usr/bin/env bash instead of #!/bin/bash.

I'm pretty sure that's two different issues.

1) #!/usr/bin/env bash vs #!/bin/bash is a long-standing discussion with opinions on both sides. Debian docs generally advocate #!/bin/bash (but see #2).
https://www.baeldung.com/linux/bash-shebang-lines

2) Usermerge means that files previously in places like /bin or /sbin will all be under /usr. I think that migration is supposed to be finally complete on Trixie (other OSs finished it years ago). I previously tried using a shebang of #!/usr/bin/bash in a script in a package built on Bookworm and it was rejected by Lintian. But I've just now confirmed that on Bookworm both #!/bin/bash and #!/usr/bin/bash work in a user script. Which we are supposed to use on Trixie I'm not yet clear, but it might well turn out to be #!/usr/bin/bash. When the Debian documents will all be updated to reflect this is another question...

johnraff · 2024-06-30 02:49:08

micko01 wrote:

hhh wrote:
@micko01, I get an error with your script...
sh pick.sh
pick.sh: 36: export: Illegal option -f
pick.sh: 36: export: Illegal option -f
should be
bash pick.sh
coz
export -f
is a bashism.

Or since pick.sh has a bash shebang anyway, just make sure it's executable and run ./pick.sh

micko01 · 2024-06-30 11:36:43

Repo is renamed from "trixie" to "carbon-trixie" -- just for disambiguation !!!

see https://github.com/01micko/01micko.github.io

Same packages, just some debian_version numbers fixed at my end.

johnraff · 2024-07-01 05:59:17

Great stuff!

We should put out an Official Announcement before long. Or do you want to wait till there are a few more packages in there?

hhh · 2024-07-03 12:45:05

micko01 wrote:

BTW - GTK4 sucks! The developers hate theming apparently so only choices are adwaita light or dark.
add this to /etc/environment for dark (might need a reboot)
export GTK_THEME=Adwaita:dark

You can also change the theme to dark via ~/.config/gtk-4.0/settings.ini

[Settings]
gtk-application-prefer-dark-theme=1

... or, how I do it, via gsettings. In dconf-editor, org>gnome>desktop>interface>color-scheme>prefer-dark

hhh · 2024-07-03 13:21:50

Oh, the Ubuntu themes Yaru work with gtk4 and are in the Debian repo, along with their matching icon themes and a cursor theme (and a sound theme and gnome-shell themes). It offer light and dark themes with 9 different selected-background colors, and matching icons...

https://packages.debian.org/sid/yaru-theme-gtk

https://packages.debian.org/sid/yaru-theme-icon

hhh · 2024-07-03 16:22:41

re: Adwaita theming, although it has been archived, the Gradience project can theme Adwaita's or Adwaita's selected-background/accent color. It's only available as a flatpak...

https://flathub.org/apps/com.github.Gra … .Gradience

Project homepage...

https://github.com/GradienceTeam/Gradience

It requires adw-gtk...

https://github.com/lassekongo83/adw-gtk3

Here's a muted accent color to match my funky wallpaper, showing thunar (gtk3) and gnome-music (gtk4)...

If you're thinking "That's a lot of hoops to jump through to change one blue color", you'd be right. Let's just say I'm really not a fan of having only one accent color available.

hhh · 2024-07-06 15:11:01

I've gone ahead and pushed by package of nwg-look to my fork...

https://github.com/hhhorb/01micko_hhhor … _amd64.deb

Click "view raw" to download it.

nwg-look is a Wayland replacement for lxappearance. The package was made with checkinstall, so it doesn't meet the criteria for inclusion in @micko01's repo. My attempts at building it with debuild all failed due to its being built with golang, but it's such a handy tool to have for labwc that I thought someone might want a package to hold them over until the Debian GO Team gets around to building it properly.

hhh · 2024-07-06 15:12:06

Link to my walkthrough of setting up labwc/wlroots on trixie or sid...

https://forums.bunsenlabs.org/viewtopic … 20#p135820

johnraff · 2024-07-07 02:47:55

Impressive to see all this work going into Wayland adaptation.

hhh wrote:

nwg-look is a Wayland replacement for lxappearance.

Is nwg-look also usable on X by any chance? It would be great to keep the number of mutually incompatible apps we ship down to the minimum possible, by combinations of:
a) moving to new apps that work on both X and Wayland
b) waiting for the apps we use to catch up
c) adapting our bunsen-* packages to work on both platforms
d) writing wrapper scripts that let an app work on the platform it wasn't made for
or, if all else fails:
e) shipping different apps for X and Wayland systems

Of course there is going to be a certain number of e) apps...

micko01 · 2024-07-07 10:44:24

johnraff wrote:

Impressive to see all this work going into Wayland adaptation.
hhh wrote:
nwg-look is a Wayland replacement for lxappearance.
Is nwg-look also usable on X by any chance? It would be great to keep the number of mutually incompatible apps we ship down to the minimum possible, by combinations of:
a) moving to new apps that work on both X and Wayland
b) waiting for the apps we use to catch up
c) adapting our bunsen-* packages to work on both platforms
d) writing wrapper scripts that let an app work on the platform it wasn't made for
or, if all else fails:
e) shipping different apps for X and Wayland systems
Of course there is going to be a certain number of e) apps...

I'm pretty sure nwg-look can be used on X, as can azote (nitrogen replacement). Just need the right depends, but that's ok I can add them to my azote package and bump the debian revision number to 0.2.

Last edited by micko01 (2024-07-07 10:45:30)

micko01 · 2024-07-07 10:50:06

^^^^ @hhh I've built stuff with go before so I'll have a go (pun intended ). I usually cheat a bit and download some debian source package built with specified programming language and reap the goods from the debian/rules file.

EDIT: xcur2png package is uploaded. go is not being nice, getting proxy errors. Don't know why.

Last edited by micko01 (2024-07-07 12:18:47)

micko01 · 2024-07-08 06:10:53

@hhh while nwg-look might look good there are too many bugs in it for me. The only thing that works almost 100% is the cursor change!

I managed to build it properly, and I'll document it here for safe keeping, in case we need to build something else with golang. It requires dh-make-golang which is brilliant, creates the package/debian directory perfectly!

Let me know if you want me to add it (nwg-look) to the repo; between us we might be able to fix the bugs and come up with something reasonable.

sudo apt install dh-make-golang -y

# in the dir where you _want_ to make the package, gets the source and all - really good for git builds

dh-make-golang make -git_revision 67a4f67 -force_prerelease -type p github.com/nwg-piotr/nwg-look

vim debian/control

*** hack, hack, hack *** # fixup name, depends

vim debian/changelog

*** hack, hack, hack *** # fixup

vim debian/copyright # fixup

*** hack, hack, hack ***

vim ../itp-nwg-look.txt

*** hack, hack, hack ***

### install build depends (generated automagically in debian/control)

debuild -rfakeroot

(wait a while as several git repos are downloaded and built)

xcurtopng still might be useful.

Anyway, labwc-tweaks-gtk or labwc-tweaks (QT version) written in C and C++ respectively could fill our niche. Not as pretty but seem stable. I have already build 'tweaks-gtk the 'debian way' so know how to do.

There is a problem however with some of the Boron icon themes in that they are only an index.theme file. Both nwg-look and labwc-tweaks choke on this. 'tweaks is an easy fix either at the bunsen end or the labwc-tweaks end, so no big deal.

I'll have a think about the solutions.

johnraff · 2024-07-08 06:22:33

micko01 wrote:

There is a problem however with some of the Boron icon themes in that they are only an index.theme file. Both nwg-look and labwc-tweaks choke on this.

Most of the Numix-Bunsen icon themes are like that, inheriting various "common" themes to save duplication of icons. I think eg Papirus does it with lots of symlinks, but the index.theme method with inheritance struck me as more elegant. Do nwg-look and labwc-tweaks have problems with icon inheritance in general?

micko01 · 2024-07-08 06:56:53

johnraff wrote:

Most of the Numix-Bunsen icon themes are like that, inheriting various "common" themes to save duplication of icons. I think eg Papirus does it with lots of symlinks, but the index.theme method with inheritance struck me as more elegant. Do nwg-look and labwc-tweaks have problems with icon inheritance in general?

Not necessarily. IIRC I wrote the icon theme code in labwc-tweaks or it could have been edited later by @malm but I think I can easily fix it. On my current system I just put in a dummy directory and it picks up all of the icon themes.

Actually I like the elegance and simplicity of the index.theme approach

Not going to dive into the nwg-look code to see whats's up, but I will try to rebuild it with an 'install' file as some things didn't make it to the build, so maybe why I was having problems.

EDIT:
FWIW I've uploaded a rebuilt, missing files in place, nwg-look. For the current state of the repo see the main (first) post.

Last edited by micko01 (2024-07-08 08:43:22)

johnraff · 2024-07-08 09:24:10

I've built a dillo-3.1.1 from here:
https://github.com/dillo-browser/dillo
https://github.com/dillo-browser/dillo/ … tag/v3.1.1

It's built from the tarball provided on the 3.1.1 release page, not from the git repo directly.

PR sent: https://github.com/01micko/01micko.github.io/pull/5

There are several different people maintaining dillo forks, but the one I picked looks like possibly the most conservative and concerned with bug-squashing rather than new features.

---
Couple of questions prospective repo contributors might ask:

1) Would you like notification of new packages other than the PR itself, and if so, is this the best place to post them?

2) I set the suite to carbon-trixie to match what you set in your repo itself. Is that to be preferred? I don't know how reprepro deals with attempts to add packages claiming to be for other suites, like trixie, or carbon. Either of those, in fact, would avoid an error message from lintian when building, but I don't think it's that important.

3) The .changes file lists .buildinfo along with the others in the set, so I included it although it's not mentioned in your user guide. Any preference there?

micko01 · 2024-07-08 11:17:53

johnraff wrote:

I've built a dillo-3.1.1 from here:
https://github.com/dillo-browser/dillo
https://github.com/dillo-browser/dillo/ … tag/v3.1.1
It's built from the tarball provided on the 3.1.1 release page, not from the git repo directly.
PR sent: https://github.com/01micko/01micko.github.io/pull/5
There are several different people maintaining dillo forks, but the one I picked looks like possibly the most conservative and concerned with bug-squashing rather than new features.

Already had it uploaded before you posted

Couple of questions prospective repo contributors might ask:
1) Would you like notification of new packages other than the PR itself, and if so, is this the best place to post them?

I get emails notifications from github, thats enough.

2) I set the suite to carbon-trixie to match what you set in your repo itself. Is that to be preferred? I don't know how reprepro deals with attempts to add packages claiming to be for other suites, like trixie, or carbon. Either of those, in fact, would avoid an error message from lintian when building, but I don't think it's that important.

carbon-trixie, trixie, carbon, doesn't matter. reprepro has an option to handle mis-matched suites so no issue. I just try to reduce lintian warnings, not worried about eliminating them, in fact I can't using an NMU debian version. Of course errors are fatal.

3) The .changes file lists .buildinfo along with the others in the set, so I included it although it's not mentioned in your user guide. Any preference there?

Actually, the .changes is the most important one!

01micko@github/README.md wrote:

If you have packages to add then I need the full suite of files produced

Plus it's super easy to add all four or five files produced with one simple command. Here's what I did with dillo and it adds everything. Nothing more to do other than git commit; git push.

reprepro  --ignore=wrongdistribution  include carbon-trixie ../../dillo/dillo_3.1.1-0.1~bl2_amd64.changes

.. and there's the option, --ignore=wrongdistribution that allows any suite really, could be some obscure name, wouldn't matter.

#41 2024-06-29 15:17:30

Re: BunsenLabs-wayland repository - in development

#42 2024-06-30 00:36:20

Re: BunsenLabs-wayland repository - in development

zenity

yad

#43 2024-06-30 00:40:00

Re: BunsenLabs-wayland repository - in development

#44 2024-06-30 02:42:51

Re: BunsenLabs-wayland repository - in development

#45 2024-06-30 02:49:08

Re: BunsenLabs-wayland repository - in development

#46 2024-06-30 11:36:43

Re: BunsenLabs-wayland repository - in development

#47 2024-07-01 05:59:17

Re: BunsenLabs-wayland repository - in development

#48 2024-07-03 12:45:05

Re: BunsenLabs-wayland repository - in development

#49 2024-07-03 13:21:50

Re: BunsenLabs-wayland repository - in development

#50 2024-07-03 16:22:41

Re: BunsenLabs-wayland repository - in development

#51 2024-07-06 15:11:01

Re: BunsenLabs-wayland repository - in development

#52 2024-07-06 15:12:06

Re: BunsenLabs-wayland repository - in development

#53 2024-07-07 02:47:55

Re: BunsenLabs-wayland repository - in development

#54 2024-07-07 10:44:24

Re: BunsenLabs-wayland repository - in development

#55 2024-07-07 10:50:06

Re: BunsenLabs-wayland repository - in development

#56 2024-07-08 06:10:53

Re: BunsenLabs-wayland repository - in development

#57 2024-07-08 06:22:33

Re: BunsenLabs-wayland repository - in development

#58 2024-07-08 06:56:53

Re: BunsenLabs-wayland repository - in development

#59 2024-07-08 09:24:10

Re: BunsenLabs-wayland repository - in development

#60 2024-07-08 11:17:53

Re: BunsenLabs-wayland repository - in development

Board footer