The Wayland plugin for Carbon

johnraff · Yesterday 02:55:19

hhh wrote:

I also have xdg-desktop-portal-wlr installed, we should include that too, IMO

OK I knew nothing about this one, let's put it in if it's useful. What is it good for?

There's a whole load of them:

john@carbon:~$ apt list 'xdg-desktop-portal*'
xdg-desktop-portal-dev/stable 1.20.3+ds-1 all
xdg-desktop-portal-gnome/stable 48.0-2 amd64
xdg-desktop-portal-gtk/stable,now 1.15.3-1 amd64 [installed]
xdg-desktop-portal-hyprland/stable-backports 1.3.11-1~bpo13+1 amd64
xdg-desktop-portal-kde/stable 6.3.5-1 amd64
xdg-desktop-portal-lxqt/stable 1.1.0-2+b1 amd64
xdg-desktop-portal-phosh/stable 0.46.0-2 amd64
xdg-desktop-portal-tests/stable 1.20.3+ds-1 amd64
xdg-desktop-portal-wlr/stable 0.7.1-2 amd64
xdg-desktop-portal-xapp/stable 1.1.0-1 amd64
xdg-desktop-portal/stable,now 1.20.3+ds-1 amd64 [installed,automatic]

https://wiki.archlinux.org/title/XDG_Desktop_Portal <- somewhat interesting

Last edited by johnraff (Yesterday 03:07:21)

hhh · Yesterday 03:05:59

johnraff wrote:

hhh wrote:
I also have xdg-desktop-portal-wlr installed, we should include that too, IMO
OK I knew nothing about this one, let's put it in if it's useful. What is it good for?

Screenshots and screencasts...
https://packages.debian.org/sid/xdg-desktop-portal-wlr

We only need *-portal-gtk, but think of the poor scrots!

hhh · Yesterday 03:13:30

xdg-desktop-portal is Snap and Flatpak support? I didn't know that.

https://packages.debian.org/sid/xdg-desktop-portal

OK, *-portal-gtk description sheds more light on the topic...

xdg-desktop-portal-gtk provides a GTK+/GNOME implementation for the desktop-agnostic xdg-desktop-portal service. This allows sandboxed applications to request services from outside the sandbox using GTK+ GUIs (app chooser, file chooser, print dialog) or using GNOME services (session manager, screenshot provider).

So this also includes AppImages, I would think.

https://packages.debian.org/sid/xdg-desktop-portal-gtk

Last edited by hhh (Yesterday 03:16:36)

johnraff · Yesterday 05:05:46

We've already installed xdg-desktop-portal-gtk in the X11 system because @cog found it was needed to get dark GTK4 themes by default, and you have also referred to it in the past:
https://forums.bunsenlabs.org/viewtopic.php?id=9606&p=2
https://forums.bunsenlabs.org/viewtopic … 11#p147411
https://forums.bunsenlabs.org/viewtopic.php?id=9534
https://forums.bunsenlabs.org/viewtopic.php?id=9571

johnraff · Yesterday 07:53:07

rc.xml

Here is labwc's complete rc.xml showing all the default values:
https://github.com/labwc/labwc/blob/mas … rc.xml.all
and here is a very simple rc.xml:
https://github.com/labwc/labwc/blob/master/docs/rc.xml

We could go three ways:
1) ship a minimal rc.xml with only the values which we want to change - labwc will use default for all the others.
2) ship a full rc.xml with all the default values written in so users can immediately see what they are.
3) ship an rc.xml with our values set, and all the default values present but commented-out.

Preferences?

---
Sub-question:
a) make the labwc rc.xml as close as possible to the openbox file so similar sections appear in the same order?
or
b) make our labwc rc.xml as close as possible to the file on labwc's github?

I'm leaning towards 2) + a) but could easily be persuaded otherwise.

---
Third question:
c) keep all the keybinds, mousebinds etc as close as possible to what we now have with openbox?
or
d) keep things as close as possible to the default labwc settings?

Last edited by johnraff (Today 01:27:30)

unklar · Yesterday 13:57:40

^suggest

3)
a)
c)

trinidad · Yesterday 17:17:43

3 might be convenient for new users and c as well.
2 would be good too either a or c.

or 2 a and a reference backup copy of 3.

Truth is IMHO labwc is so simple that whatever is best for you and maintainers is best.

TC

johnraff · Today 02:02:44

I think 3) would be an attractive option, but something I just realized: xml commenting isn't line-by-line like most formats. You can't comment out each line separately with a #, you have to comment out a whole block with .
eg snippet from picom.conf:

# Enabled client-side shadows on windows. Note desktop windows
# (windows with '_NET_WM_WINDOW_TYPE_DESKTOP') never get shadow,
# unless explicitly requested.
#
# Can be set per-window using rules.
#
# Default: false
shadow = true;

# The blur radius for shadows, in pixels.
#
# Default: 12
shadow-radius = 12;

Each line is commented separately.

But snippet from openbox's rc.xml:

  <theme>
    <name>bunsen-yaru-sage-dark</name>
    <titleLayout>NDSLIMC</titleLayout>
    <!--
      available characters are NDSLIMC, each can occur at most once.
      N: window icon
      L: window label (AKA title).
      I: iconify
      M: maximize
      C: close
      S: shade (roll up/down)
      D: omnipresent (on all desktops).
  -->
    <keepBorder>yes</keepBorder>
    <animateIconify>no</animateIconify>
    <font place="ActiveWindow">
      <name>Sans</name>
      <size>10</size>
      <!-- font size in points -->

So if option 3) is going to let users uncomment and use each entry separately, it would mean commenting-out each line individually, something like this:

<!--
  This file contains all supported config elements & attributes with
  default values.

  Values for [yes|no] can be replaced by [true|false], [on|off] or [1|0].
-->

<labwc_config>

<!--  <core> -->
<!--    <decoration>server</decoration> -->
<!--    <gap>0</gap> -->
<!--    <adaptiveSync>no</adaptiveSync> -->

Quite a lot of work for BL developers. And for users too, to delete both  instead of a single # when they want to enable a line.

So maybe either option 2) (full set of configs, with many of them at default setting)
or 1) (non-default configs only) + Trinidad's suggestion of a copy of the full rc.xml in the same directory for reference.

---
I think we're agreed that the keybindings and mousebindings for labwc should be as close as we can get them to what BL is now setting for openbox, so users don't have too many surprises. ie a) + c)

unklar · Today 07:01:01

^Thanks, @johnraff for your clear explanation. I hadn't considered that.

You are the master here, so my suggestion would be to put the least effort into the configuration.
If the USER has a copy in the background, he will be more willing to try out the 'New labwc' in BL.

#41 Yesterday 02:55:19

Re: The Wayland plugin for Carbon

#42 Yesterday 03:05:59

Re: The Wayland plugin for Carbon

#43 Yesterday 03:13:30

Re: The Wayland plugin for Carbon

#44 Yesterday 05:05:46

Re: The Wayland plugin for Carbon

#45 Yesterday 07:53:07

Re: The Wayland plugin for Carbon

#46 Yesterday 13:57:40

Re: The Wayland plugin for Carbon

#47 Yesterday 17:17:43

Re: The Wayland plugin for Carbon

#48 Today 02:02:44

Re: The Wayland plugin for Carbon

#49 Today 07:01:01

Re: The Wayland plugin for Carbon

Board footer