Openbox with rounded corners

beaker · 2017-01-13 06:18:00

Oh yes some feedback.
It all installed well on stable 64bit. The rounded corners theme downloaded and installed ok. Was able to adjust 'roundness' as required. All good.

cloverskull · 2017-01-16 17:05:21

Not sure if anyone noticed, but debian 8.7 includes a a few updates to openbox. Should we patch this version with the rounded corners updates to be synchronous with debian's releases?

https://www.debian.org/News/2017/20170114

Head_on_a_Stick · 2017-01-16 19:14:00

^ Yes, good call, I was intending to do that, thanks for the bump smile

EDIT: I have a headache, this will have to wait until tomorrow, sorry folks.

Last edited by Head_on_a_Stick (2017-01-16 22:25:01)

Head_on_a_Stick · 2017-01-17 22:05:36

I have updated the packages, the name is a bit weird because the OBS won't accept the dash used by Debian version numbers but they should still install just fine.

martix · 2017-01-21 21:20:31

I had a guess that I'm missing here something but it turns out that it is indeed working fine. Thank you for showing in the right direction and the .deb file, here are the steps:

1. Download the .deb file for #BĹ:

wget download.opensuse.org/repositories/home:/Head_on_a_Stick:/openbox-rounded/Debian_8.0/amd64/openbox_3.5.2-8.deb8u1.2_amd64.deb

2. Install

gdebi openbox_3.5.2-8.deb8u1.2_amd64.deb

3. Check

apt-cache policy openbox

openbox:
  Installed: 3.5.2-8.deb8u1.1

4. Edit .rc (after keepBorder):

<cornerRadius>4</cornerRadius>

5. Restart

openbox --restart

Edit: Replaced the first link with the new version. At step 5 reconfigure did not do the job, with restart it works.

Last edited by martix (2017-01-22 09:47:09)

Head_on_a_Stick · 2017-01-21 21:58:36

martix wrote:

I guess I'm missing here something

No, your steps look fine to me.

I have just rebuilt the package with another version bump, try to install the new .debs in 10 minutes or so when they finish building, the links I have already posted should always point to the current version.

EDIT: oops, made the same naming error again, give me a bit more.

I have just tested the newly-built .debs and it works on my BL system.

Last edited by Head_on_a_Stick (2017-01-21 22:01:09)

Head_on_a_Stick · 2017-01-21 22:46:33

The new packages are built and ready to download.

Also:

martix wrote:

Edit .rc (after keepBorder):

      <roundCorners>yes</roundCorners>
    <invisibleHandles>yes</invisibleHandles>
    <cornerRadius>4</cornerRadius>

Only the <cornerRadius></cornerRadius> line is needed, the other lines are from the Raspbian patch which was replaced with cpoakes' version wink

cpoakes · 2017-01-22 01:00:00

Ditto. The <roundCorners> and <invisibleHandles> parameters are ignored, but can stay in your file if you are also experimenting with the RPi version.

martix · 2017-01-22 09:48:19

Thank you, it is working fine now. Looks great! Corrected the steps above as well.

o9000 · 2017-01-23 10:16:03

That's OK, but what I would prefer is taking this a step further and adding support for XFWM themes in Openbox. The concept is very simple: for each part of the window frame (e.g. title bar, upper right corner, close button), an image is provided. For buttons and corners, the image is drawm as is; for title bar and borders, it is tiled horizontally or vertically to the entire window size. The button geometry is computed based on the image. So a theme would look like this: https://gitlab.com/o9000/ChromeDark/tree/master/xfwm4

What do you think?

hhh · 2017-03-03 14:34:58

^I don't understand, why would you want to replace one rc file with 2 dozen .xpm files, not including the buttons? Theming Xfwm4 is a gigantic PITA just for this reason.

@HoaS, is it too much to ask for stretch builds of this?

@all who have been testing, does this affect the OB root menu (please say yes!)?

I'm asking because xfce4-notifyd now uses GTK3 and does not accept a border-radius value less than 1, which makes BL's current theming inconsistent (windows and menu are square, notifications are round. If we could have all 3 elements (window borders, root menu and notifications) with the same radius value, I would be a happy boy.

cpoakes · 2017-03-03 19:52:46

hhh wrote:

@all who have been testing, does this affect the OB root menu (please say yes!)?

No, corner clipping is only applied to decorated windows. Without reviewing actual source, I am guessing that root-menu, client-menu, and client-list-combined-menu can get the same mods. I will take a look.

hhh wrote:

I'm asking because xfce4-notifyd now uses GTK3 and does not accept a border-radius value less than 1, which makes BL's current theming inconsistent (windows and menu are square, notifications are round.

Is the round corner problem restricted to xfce4-notifyd-config? Can you manually configure square corners in the gtk3 theme? While XFCE distributes themes with rounded corners, I would be surprised if they intended to enforce round corners on all theme devs. I would categorize this as a bug. Especially if manual configuration works and the problem is restricted to xfce4-notifyd-config. Have you reported it as such?*

Furthermore, my reading of the XFCE 4.12 changelog indicates compling xfce4-notifyd with GTK3 is optional. You may be able to recompile with GTK2 and have the problem just go away. The release is already a hotch-potch of GTK2/GTK3 executables.

*Reporting as a bug now will not get stretch fixed. BL will need to compile its own binary. (If memory serves, this mirrors the problem with xfce4-power-manager at the jessie testing-to-stable transition).

cpoakes · 2017-03-03 19:59:14

o9000 wrote:

That's OK, but what I would prefer is taking this a step further and adding support for XFWM themes in Openbox. The concept is very simple: for each part of the window frame (e.g. title bar, upper right corner, close button), an image is provided. For buttons and corners, the image is drawm as is; for title bar and borders, it is tiled horizontally or vertically to the entire window size. The button geometry is computed based on the image. So a theme would look like this: https://gitlab.com/o9000/ChromeDark/tree/master/xfwm4
What do you think?

The code changes are non-trivial. It essentially requires combining the xfwm window rendering code into OB. If you like xfwm theming and rendering and merely want OB-style root menu handling, it is probably easier to add OB features to the xfwm code.

Sorry it took so long to respond. Intended to get to it but never did.

hhh · 2017-03-03 20:07:25

^^I haven't looked into all that, nor reported any bugs. I'm rather busy with 'real life' ATM.

And a confession which some here already know... although I have managed to crack live-build's cryptic manual and build our first ISOs, modify existing themes to create the Bunsen ones, backport packages and teach myself XHTML/CSS (quite rusty on that now, though), I have never taken a computer science class and only began learning my first programming language, JavaScript, last week. I'm starting by working through the w3schools' online tutorials.

That's why any tutorial I post is very hand-hold-y... I've found many tutorials make assumptions about a user's knowledge and they've been fairly worthless to me on many occasions.

cpoakes · 2017-03-03 20:28:58

^Of course, merely suggestions. We do what we have time for.

Head_on_a_Stick · 2017-03-03 20:49:07

hhh wrote:

@HoaS, is it too much to ask for stretch builds of this?

Nothing is too much for the Aitch Cube:

https://drive.google.com/open?id=0BxKgG … DNjdnJsaEk

Untested though, good luck!

big_smile

hhh · 2017-03-03 21:44:25

^I'm sorry, HoaS, I forgot to specify that I'm on i386.

Head_on_a_Stick · 2017-03-03 21:46:48

hhh wrote:

I'm on i386.

Ah, right, OK.

Give me a bit, I'll rustle up a container...

At least this build will be clean angel

EDIT: systemd-nspawn doesn't work if you're booting with runit...

roll

Last edited by Head_on_a_Stick (2017-03-03 22:00:49)

Head_on_a_Stick · 2017-03-03 22:36:14

@cpoakes: your patch doesn't quite apply cleanly to the stretch version; I used:

apt-get source openbox && cd openbox*
dch --nmu
quilt import -P rounded-corners.patch cpoakes.patch
quilt push
debuild -us -uc

The error was:

empty@Helium:~/openbox-3.6.1$ debuild -us -uc
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package openbox
dpkg-buildpackage: info: source version 3.6.1-4.1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by  <empty@Helium>
 dpkg-source --before-build openbox-3.6.1
dpkg-buildpackage: info: host architecture i386
 fakeroot debian/rules clean
dh clean
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/empty/openbox-3.6.1'
rm -f openbox.1
#rm -f kdetrayproxy.1
rm -f gnome-panel-control.1
rm -f gdm-control.1
dh_auto_clean
make[1]: Leaving directory '/home/empty/openbox-3.6.1'
   dh_autoreconf_clean
   dh_clean
 dpkg-source -b openbox-3.6.1
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building openbox using existing ./openbox_3.6.1.orig.tar.gz
patching file openbox/config.c
Hunk #2 FAILED at 703.
Hunk #3 succeeded at 1099 (offset 20 lines).
1 out of 3 hunks FAILED
patching file openbox/config.h
patching file openbox/frame.c
patching file openbox/framerender.c
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'rounded-corners.patch' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/rounded-corners.patch/ --reject-file=- < openbox-3.6.1.orig.54ejyh/debian/patches/rounded-corners.patch gave error exit status 1
dpkg-buildpackage: error: dpkg-source -b openbox-3.6.1 gave error exit status 2
debuild: fatal error at line 1116:
dpkg-buildpackage -rfakeroot -us -uc failed

Using `quilt refresh` let the package build successfully.

@hhh: here is the i386 .deb:

https://drive.google.com/open?id=0BxKgG … WFVNFM1OGc

hhh · 2017-03-03 22:44:00

^Thanks a million! The library is closing, I'll post back when I can.

hhh · 2017-03-03 23:32:43

It installed with no problem, thanks! And if I set the radius to 1 for windows and 2 for notifications it matches, but I can't say I'm thrilled with how it looks at 1280x800. Scrot post when I can.

Still, this is a nice option to have for stretch (as well as now).

Last edited by hhh (2017-03-03 23:35:15)

cpoakes · 2017-03-04 07:25:52

@HoaS - I'm in the midst of adapting the code for rounded corners on the menus. I am going to bang on it for a while. Once I am satisfied, I'll build the patch. Then we can see how it works with stretch. Better use of my time than debugging the last patch.

@hhh - The binary alpha mask definitely constitutes a kludge; "doing it right" is non-trivial. I don't care for the jaggies on low resolution, but at 141 DPI (1920x1080) it looks pretty good.

ohnonot · 2017-03-04 08:41:54

o9000 wrote:

taking this a step further and adding support for XFWM themes in Openbox.

use fluxbox, you get both: config-based and pixmap-based.
i hate pixmap-based. doesn't scale well and is indeed a PITA to create.
But it's the format of choice for almost everything that's older than 15 years, so i guess it must be fast.

o9000 · 2017-03-04 11:07:07

I don't think the main advantage of pixmaps is speed, it is the lower code complexity. Drawing a pixmap is very easy. All you need is the width, height, position and transparency layer and you're done. By contrast, parsing config files describing the color and geometry of the borders and buttons, and then drawing, scaling, updating them accordingly needs a lot code that's much more complex. That's why it takes forever to make a small change such as drawing rounded corners.

You guys keep saying it's a pain to draw the pixmaps in GIMP. I disagree. It only takes a few hours to make an entire theme, even without strong GIMP skills. By contrast, look at how much it takes to make something as simple as rounded corners with the other approach. You've been working on it for weeks.

But I understand why it might not be a good idea to switch to pixmaps at this point. Openbox just wasn't designed to work this way, and it might be difficult to change.

Anyways, I don't have time to help with this, and I'm not saying anything constructive, so I'll unsubscribe. Good luck.

hhh · 2017-03-04 15:00:47

cpoakes wrote:

The release is already a hotch-potch of GTK2/GTK3 executables.

Yes, that's what I'm seeing. xfwm4 and xfce4-session, for example, still depend on libgtk-2.

You may be able to recompile with GTK2 and have the problem just go away.

xfce4-notifyd depends on libgtk-3-0, so I don't think so. I'm wondering if I can build the jessie version on stretch, but I have a feeling I'll get screwed by the dependencies.

Anyway, I'll start a new thread for this if I make any progress.

-edit- Looks like this is the problem (if radius == 0 then radius = 6, and the preceding reason)...

diff --git a/xfce4-notifyd/xfce-notify-window.c b/xfce4-notifyd/xfce-notify-window.c
index 6024a2d..686d4b1 100644
--- a/xfce4-notifyd/xfce-notify-window.c
+++ b/xfce4-notifyd/xfce-notify-window.c
@@ -359,33 +359,37 @@ xfce_notify_window_draw_rectangle (XfceNotifyWindow *window,
     border_width = get_max_border_width (context, state);
     border_padding = border_width / 2.0;
     
-    if(radius < 1) {
-        cairo_rectangle(cr, 0, 0, widget_allocation.width,
-                        widget_allocation.height);
-    } else {
-        cairo_move_to(cr, border_padding, radius + border_padding);
-        cairo_arc(cr, radius + border_padding,
-                  radius + border_padding, radius,
-                  M_PI, 3.0*M_PI/2.0);
-        cairo_line_to(cr,
-                      widget_allocation.width - radius - border_padding,
-                      border_padding);
-        cairo_arc(cr,
-                  widget_allocation.width - radius - border_padding,
-                  radius + border_padding, radius,
-                  3.0*M_PI/2.0, 0.0);
-        cairo_line_to(cr, widget_allocation.width - border_padding,
-                      widget_allocation.height - radius - border_padding);
-        cairo_arc(cr, widget_allocation.width - radius - border_padding,
-                  widget_allocation.height - radius - border_padding,
-                  radius, 0.0, M_PI/2.0);
-        cairo_line_to(cr, radius + border_padding,
-                      widget_allocation.height - border_padding);
-        cairo_arc(cr, radius + border_padding,
-                  widget_allocation.height - radius - border_padding,
-                  radius, M_PI/2.0, M_PI);
-        cairo_close_path(cr);
+    /* Always use a small rounded corners. This should not be necessary in 
+     * theory, as Adwaita defined border-radius: 0 0 6px 6px; for the 
+     * app-notification and osd css classes. The problem is that Gtk for some
+     * reason gets the border-radius as gint and not as GtkBorder. Getting 
+     * this way the first value only, which is 0. */
+    if ( radius == 0 ) {
+        radius = 6;
     }

#51 2017-01-13 06:18:00

Re: Openbox with rounded corners

#52 2017-01-16 17:05:21

Re: Openbox with rounded corners

#53 2017-01-16 19:14:00

Re: Openbox with rounded corners

#54 2017-01-17 22:05:36

Re: Openbox with rounded corners

#55 2017-01-21 21:20:31

Re: Openbox with rounded corners

#56 2017-01-21 21:58:36

Re: Openbox with rounded corners

#57 2017-01-21 22:46:33

Re: Openbox with rounded corners

#58 2017-01-22 01:00:00

Re: Openbox with rounded corners

#59 2017-01-22 09:48:19

Re: Openbox with rounded corners

#60 2017-01-23 10:16:03

Re: Openbox with rounded corners

#61 2017-03-03 14:34:58

Re: Openbox with rounded corners

#62 2017-03-03 19:52:46

Re: Openbox with rounded corners

#63 2017-03-03 19:59:14

Re: Openbox with rounded corners

#64 2017-03-03 20:07:25

Re: Openbox with rounded corners

#65 2017-03-03 20:28:58

Re: Openbox with rounded corners

#66 2017-03-03 20:49:07

Re: Openbox with rounded corners

#67 2017-03-03 21:44:25

Re: Openbox with rounded corners

#68 2017-03-03 21:46:48

Re: Openbox with rounded corners

#69 2017-03-03 22:36:14

Re: Openbox with rounded corners

#70 2017-03-03 22:44:00

Re: Openbox with rounded corners

#71 2017-03-03 23:32:43

Re: Openbox with rounded corners

#72 2017-03-04 07:25:52

Re: Openbox with rounded corners

#73 2017-03-04 08:41:54

Re: Openbox with rounded corners

#74 2017-03-04 11:07:07

Re: Openbox with rounded corners

#75 2017-03-04 15:00:47

Re: Openbox with rounded corners

Board footer