Re: Patch to enable XFT on lemonbar

2020-01-03 Thread Aaron Bieber
On Thu, 02 Jan 2020 at 09:18:39 -0700, Aaron Bieber wrote:
> On Thu, 02 Jan 2020 at 16:31:34 +0100, Jeremie Courreges-Anglas wrote:
> > On Sun, Feb 17 2019, Ingo Feinerer  wrote:
> > > On Sun, Feb 17, 2019 at 10:30:15AM +0100, Peter Hessler wrote:
> > >> On 2019 Feb 17 (Sun) at 09:56:39 +0100 (+0100), Ingo Feinerer wrote:
> > >> :On Sun, Feb 17, 2019 at 10:36:42AM +0200, Timo Myyrä wrote:
> > >> :> For some reason the compilation gives warning on pledge although 
> > >> unistd.h is included:
> > >> :> lemonbar.c:1541:9: warning: implicit declaration of function 'pledge' 
> > >> is invalid in C99 [-Wimplicit-function-declaration]
> > >> :> if (pledge("stdio", NULL) == -1)
> > >> :> ^
> > >> :> 1 warning generated.
> > >> :
> > >> :That is because of
> > >> :
> > >> :#define _POSIX_C_SOURCE 200809L
> > >> :
> > >> :in lemonbar.c
> > >> :
> > >> :pledge() still works (in my tests I tried the pledge() call at different
> > >> :earlier positions which lead to program termination) so I just ignored
> > >> :this warning.
> > >> 
> > >> No.  You need to make sure the proper prototype is declared for all
> > >> functions.
> > >
> > > New version attached which deletes the _POSIX_C_SOURCE #define.
> > 
> > Sounds fair.  An alternative would have been to also define _BSD_SOURCE.
> > Note that a pledge(2) failure ought to be fatal, I tweaked that in the
> > updated tarball attached.
> > 
> > > OK?
> > 
> > Updated version with amended pledge patch, PERMIT_PACKAGE=Yes and
> > a tweak to honor LDFLAGS.  I'm looking at this submission now because
> > Tom Murphy brought it up some days ago:
> > 
> >   https://marc.info/?l=openbsd-ports&m=157727376803891&w=2
> > 
> > Not tested but looks good ports-wise, ok jca@ to import
> > 
> Tested as a replacement for the version I have in WIP - working well here!
> 
> OK abieber@ as well. I will zap the wip port once I see this committed

I imported this and missed Ingo in the commit message. I am very sorry for that
and would like to publicly apologize to Ingo! I am very sorry! I had the
intention of including everyone, but in my haste missed the actual maintainer!

I also stole the commit. Again, very sorry!

> 
> > 
> > -- 
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 
> 
> -- 
> PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE
> 

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: Patch to enable XFT on lemonbar

2020-01-02 Thread Aaron Bieber
On Thu, 02 Jan 2020 at 16:31:34 +0100, Jeremie Courreges-Anglas wrote:
> On Sun, Feb 17 2019, Ingo Feinerer  wrote:
> > On Sun, Feb 17, 2019 at 10:30:15AM +0100, Peter Hessler wrote:
> >> On 2019 Feb 17 (Sun) at 09:56:39 +0100 (+0100), Ingo Feinerer wrote:
> >> :On Sun, Feb 17, 2019 at 10:36:42AM +0200, Timo Myyrä wrote:
> >> :> For some reason the compilation gives warning on pledge although 
> >> unistd.h is included:
> >> :> lemonbar.c:1541:9: warning: implicit declaration of function 'pledge' 
> >> is invalid in C99 [-Wimplicit-function-declaration]
> >> :> if (pledge("stdio", NULL) == -1)
> >> :> ^
> >> :> 1 warning generated.
> >> :
> >> :That is because of
> >> :
> >> :#define _POSIX_C_SOURCE 200809L
> >> :
> >> :in lemonbar.c
> >> :
> >> :pledge() still works (in my tests I tried the pledge() call at different
> >> :earlier positions which lead to program termination) so I just ignored
> >> :this warning.
> >> 
> >> No.  You need to make sure the proper prototype is declared for all
> >> functions.
> >
> > New version attached which deletes the _POSIX_C_SOURCE #define.
> 
> Sounds fair.  An alternative would have been to also define _BSD_SOURCE.
> Note that a pledge(2) failure ought to be fatal, I tweaked that in the
> updated tarball attached.
> 
> > OK?
> 
> Updated version with amended pledge patch, PERMIT_PACKAGE=Yes and
> a tweak to honor LDFLAGS.  I'm looking at this submission now because
> Tom Murphy brought it up some days ago:
> 
>   https://marc.info/?l=openbsd-ports&m=157727376803891&w=2
> 
> Not tested but looks good ports-wise, ok jca@ to import
> 
Tested as a replacement for the version I have in WIP - working well here!

OK abieber@ as well. I will zap the wip port once I see this committed

> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: Patch to enable XFT on lemonbar

2020-01-02 Thread Jeremie Courreges-Anglas
On Sun, Feb 17 2019, Ingo Feinerer  wrote:
> On Sun, Feb 17, 2019 at 10:30:15AM +0100, Peter Hessler wrote:
>> On 2019 Feb 17 (Sun) at 09:56:39 +0100 (+0100), Ingo Feinerer wrote:
>> :On Sun, Feb 17, 2019 at 10:36:42AM +0200, Timo Myyrä wrote:
>> :> For some reason the compilation gives warning on pledge although unistd.h 
>> is included:
>> :> lemonbar.c:1541:9: warning: implicit declaration of function 'pledge' is 
>> invalid in C99 [-Wimplicit-function-declaration]
>> :> if (pledge("stdio", NULL) == -1)
>> :> ^
>> :> 1 warning generated.
>> :
>> :That is because of
>> :
>> :#define _POSIX_C_SOURCE 200809L
>> :
>> :in lemonbar.c
>> :
>> :pledge() still works (in my tests I tried the pledge() call at different
>> :earlier positions which lead to program termination) so I just ignored
>> :this warning.
>> 
>> No.  You need to make sure the proper prototype is declared for all
>> functions.
>
> New version attached which deletes the _POSIX_C_SOURCE #define.

Sounds fair.  An alternative would have been to also define _BSD_SOURCE.
Note that a pledge(2) failure ought to be fatal, I tweaked that in the
updated tarball attached.

> OK?

Updated version with amended pledge patch, PERMIT_PACKAGE=Yes and
a tweak to honor LDFLAGS.  I'm looking at this submission now because
Tom Murphy brought it up some days ago:

  https://marc.info/?l=openbsd-ports&m=157727376803891&w=2

Not tested but looks good ports-wise, ok jca@ to import



lemonbar-xft.tgz
Description: Binary data

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


Re: Patch to enable XFT on lemonbar

2019-02-20 Thread Ingo Feinerer
Anyone willing to give a final OK for import?
(https://marc.info/?l=openbsd-ports&m=155042965323231&w=2)

On Sun, Feb 17, 2019 at 07:52:08PM +0100, Ingo Feinerer wrote:
> New version attached which deletes the _POSIX_C_SOURCE #define.
> OK?



Re: Patch to enable XFT on lemonbar

2019-02-17 Thread Ingo Feinerer
On Sun, Feb 17, 2019 at 10:30:15AM +0100, Peter Hessler wrote:
> On 2019 Feb 17 (Sun) at 09:56:39 +0100 (+0100), Ingo Feinerer wrote:
> :On Sun, Feb 17, 2019 at 10:36:42AM +0200, Timo Myyrä wrote:
> :> For some reason the compilation gives warning on pledge although unistd.h 
> is included:
> :> lemonbar.c:1541:9: warning: implicit declaration of function 'pledge' is 
> invalid in C99 [-Wimplicit-function-declaration]
> :> if (pledge("stdio", NULL) == -1)
> :> ^
> :> 1 warning generated.
> :
> :That is because of
> :
> :#define _POSIX_C_SOURCE 200809L
> :
> :in lemonbar.c
> :
> :pledge() still works (in my tests I tried the pledge() call at different
> :earlier positions which lead to program termination) so I just ignored
> :this warning.
> 
> No.  You need to make sure the proper prototype is declared for all
> functions.

New version attached which deletes the _POSIX_C_SOURCE #define.
OK?


lemonbar-xft.tar.gz
Description: application/tar-gz


Re: Patch to enable XFT on lemonbar

2019-02-17 Thread Peter Hessler
On 2019 Feb 17 (Sun) at 09:56:39 +0100 (+0100), Ingo Feinerer wrote:
:On Sun, Feb 17, 2019 at 10:36:42AM +0200, Timo Myyrä wrote:
:> For some reason the compilation gives warning on pledge although unistd.h is 
included:
:> lemonbar.c:1541:9: warning: implicit declaration of function 'pledge' is 
invalid in C99 [-Wimplicit-function-declaration]
:> if (pledge("stdio", NULL) == -1)
:> ^
:> 1 warning generated.
:
:That is because of
:
:#define _POSIX_C_SOURCE 200809L
:
:in lemonbar.c
:
:pledge() still works (in my tests I tried the pledge() call at different
:earlier positions which lead to program termination) so I just ignored
:this warning.

No.  You need to make sure the proper prototype is declared for all
functions.


-- 
In order to make an apple pie from scratch, you must first create the
universe.
-- Carl Sagan, Cosmos



Re: Patch to enable XFT on lemonbar

2019-02-17 Thread Ingo Feinerer
On Sun, Feb 17, 2019 at 10:36:42AM +0200, Timo Myyrä wrote:
> For some reason the compilation gives warning on pledge although unistd.h is 
> included:
> lemonbar.c:1541:9: warning: implicit declaration of function 'pledge' is 
> invalid in C99 [-Wimplicit-function-declaration]
> if (pledge("stdio", NULL) == -1)
> ^
> 1 warning generated.

That is because of

#define _POSIX_C_SOURCE 200809L

in lemonbar.c

pledge() still works (in my tests I tried the pledge() call at different
earlier positions which lead to program termination) so I just ignored
this warning.



Re: Patch to enable XFT on lemonbar

2019-02-17 Thread Timo Myyrä
Ingo Feinerer  writes:

> On Fri, Feb 15, 2019 at 09:28:03AM +, Stuart Henderson wrote:
>
>> On 2019/02/15 09:45, Peter Hessler wrote:
>> > On 2019 Feb 08 (Fri) at 20:34:00 +0100 (+0100), Ingo Feinerer wrote:
>> > :Alternatively we could create a new port for the fork (e.g.,
>> > :lemonbar-xft). But since both LemonBoy/bar and krypt-n/bar have not seen
>> > :a lot of changes recently we won't miss anything important if we just
>> > :switch.
>> > 
>> > I tried running it, but it kept puking on my existing scripts.
>> > 
>> > Also, this branch is quite a few commits behind the existing one.
>> > 
>> > I'd *much* rather we not change the upstream.
>
> @phessler: Thanks for testing!
>
>> > Either a new port or the big invasive patch.  Considering how
>> > inactive both projects are, carrying a patch isn't completely
>> > terrible :/.
>> 
>> I don't see a downside to adding a new lemonbar-xft port. The two can be
>> merged later if appropriate. Just decide whether to rename files so they
>> can be installed alongside each other, or mark the conflict.
>
> Please find attached a new lemonbar-xft port.
>
> OK to import?
>
>> Please don't use _ in the package version though.
>
> Done.
>
> # $OpenBSD$
>
> COMMENT = featherweight lemon-scented bar with XFT support
>
> VERSION = 1.1.20180416
>
> DISTNAME =lemonbar-xft-${VERSION}
>
> GH_ACCOUNT =  krypt-n
> GH_PROJECT =  bar
> GH_COMMIT =   00a3fe6f3485203896156480e86014136749a221
>
> CATEGORIES =  x11
>
> MAINTAINER =  Ingo Feinerer 
>
> # MIT
> PERMIT_PACKAGE_CDROM =Yes
>
> # uses pledge()
> WANTLIB += X11 X11-xcb Xft c fontconfig freetype xcb xcb-randr
> WANTLIB += xcb-xinerama z
>
> COMPILER =base-clang ports-gcc
> COMPILER_LANGS =  c
>
> MAKE_ENV =LDFLAGS="-L${X11BASE}/lib"
>
> USE_GMAKE =   Yes
>
> NO_TEST = Yes
>
> CFLAGS += -I${X11BASE}/include
>
> ALL_TARGET =  all doc
>
> do-install:
>   ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/lemonbar-xft/
>   ${INSTALL_PROGRAM} ${WRKSRC}/lemonbar ${PREFIX}/bin/lemonbar-xft
>   ${INSTALL_MAN} ${WRKSRC}/lemonbar.1 ${PREFIX}/man/man1/lemonbar-xft.1
>   ${INSTALL_DATA} ${WRKSRC}/LICENSE ${PREFIX}/share/doc/lemonbar-xft/
>
> .include 
> SHA256 (lemonbar-xft-1.1.20180416-00a3fe6f.tar.gz) = 
> wNz3vlI37dHYiA/Zg0WIPDRDsxl6BFd6nYKuGzjDA94=
> SIZE (lemonbar-xft-1.1.20180416-00a3fe6f.tar.gz) = 16715
> $OpenBSD$
>
> Index: Makefile
> --- Makefile.orig
> +++ Makefile
> @@ -7,7 +7,7 @@ ifneq "$(GIT_DESC)" ""
>  endif
>  
>  CC   ?= gcc
> -CFLAGS += -Wall -std=c99 -Os -DVERSION="\"$(VERSION)\"" 
> -I/usr/include/freetype2
> +CFLAGS += -Wall -std=c99 -DVERSION="\"$(VERSION)\"" 
> -I${X11BASE}/include/freetype2
>  LDFLAGS += -lxcb -lxcb-xinerama -lxcb-randr -lX11 -lX11-xcb -lXft -lfreetype 
> -lz -lfontconfig
>  CFDEBUG = -g3 -pedantic -Wall -Wunused-parameter -Wlong-long \
>-Wsign-conversion -Wconversion -Wimplicit-function-declaration
> @@ -22,7 +22,7 @@ BINDIR=${PREFIX}/bin
>  all: ${EXEC}
>  
>  doc: README.pod
> - pod2man --section=1 --center="lemonbar Manual" --name "lemonbar" 
> --release="lemonbar $(VERSION)" README.pod > lemonbar.1
> + pod2man --section=1 --center="lemonbar-xft Manual" --name 
> "lemonbar-xft" --release="lemonbar-xft $(VERSION)" README.pod > lemonbar.1
>  
>  .c.o:
>   ${CC} ${CFLAGS} -o $@ -c $<
> $OpenBSD$
>
> Index: README.pod
> --- README.pod.orig
> +++ README.pod
> @@ -6,7 +6,7 @@ lemonbar - Featherweight lemon-scented bar
>  
>  =head1 SYNOPSIS
>  
> -I [-h | -g IBIB<+>IB<+>I | -b | -d | -f 
> I | -p | -n I | -u I | -B I | -F I | -U 
> I | -o I ]
> +I [-h | -g IBIB<+>IB<+>I | -b | -d | 
> -f I | -p | -n I | -u I | -B I | -F I | -U 
> I | -o I ]
>  
>  =head1 DESCRIPTION
>  
> @@ -185,7 +185,7 @@ Clicking on an area makes lemonbar output the command 
>  
>  =head1 WWW
>  
> -Lhttps://github.com/LemonBoy/bar>
> +Lhttps://github.com/krypt-n/bar>
>  
>  =head1 AUTHOR
>  
> $OpenBSD$
>
> Index: lemonbar.c
> --- lemonbar.c.orig
> +++ lemonbar.c
> @@ -1538,6 +1538,9 @@ main (int argc, char **argv)
>  // Prevent fgets to block
>  fcntl(STDIN_FILENO, F_SETFL, O_NONBLOCK);
>   
> +if (pledge("stdio", NULL) == -1)
> +fprintf(stderr, "pledge\n");
> +
>  for (;;) {
>  bool redraw = false;
>  
> lemonbar (formerly known as bar) is a lightweight bar entirely based on XCB.
> Provides full UTF-8 support, basic formatting, RandR and Xinerama support and
> EWMH compliance without wasting your precious memory.
> @comment $OpenBSD: PLIST,v$
> @bin bin/lemonbar-xft
> @man man/man1/lemonbar-xft.1
> share/doc/lemonbar-xft/
> share/doc/lemonbar-xft/LICENSE

For some reason the compilation gives warning on pledge although unistd.h is 
included:
lemonbar.c:1541:9: warning: implicit declaration of function 'pledge' is 
invalid in C99 [-Wimplicit-function-declaration]
if (pledge("stdio", NULL) == -1)
^
1 warning generated.



Timo



Re: Patch to enable XFT on lemonbar

2019-02-16 Thread Ingo Feinerer
On Fri, Feb 15, 2019 at 09:28:03AM +, Stuart Henderson wrote:
> On 2019/02/15 09:45, Peter Hessler wrote:
> > On 2019 Feb 08 (Fri) at 20:34:00 +0100 (+0100), Ingo Feinerer wrote:
> > :Alternatively we could create a new port for the fork (e.g.,
> > :lemonbar-xft). But since both LemonBoy/bar and krypt-n/bar have not seen
> > :a lot of changes recently we won't miss anything important if we just
> > :switch.
> > 
> > I tried running it, but it kept puking on my existing scripts.
> > 
> > Also, this branch is quite a few commits behind the existing one.
> > 
> > I'd *much* rather we not change the upstream.

@phessler: Thanks for testing!

> > Either a new port or the big invasive patch.  Considering how
> > inactive both projects are, carrying a patch isn't completely
> > terrible :/.
> 
> I don't see a downside to adding a new lemonbar-xft port. The two can be
> merged later if appropriate. Just decide whether to rename files so they
> can be installed alongside each other, or mark the conflict.

Please find attached a new lemonbar-xft port.

OK to import?

> Please don't use _ in the package version though.

Done.


lemonbar-xft.tar.gz
Description: application/tar-gz


Re: Patch to enable XFT on lemonbar

2019-02-15 Thread Stuart Henderson
On 2019/02/15 09:45, Peter Hessler wrote:
> On 2019 Feb 08 (Fri) at 20:34:00 +0100 (+0100), Ingo Feinerer wrote:
> :Alternatively we could create a new port for the fork (e.g.,
> :lemonbar-xft). But since both LemonBoy/bar and krypt-n/bar have not seen
> :a lot of changes recently we won't miss anything important if we just
> :switch.
> 
> I tried running it, but it kept puking on my existing scripts.
> 
> Also, this branch is quite a few commits behind the existing one.
> 
> I'd *much* rather we not change the upstream.  Either a new port or the
> big invasive patch.  Considering how inactive both projects are,
> carrying a patch isn't completely terrible :/.

I don't see a downside to adding a new lemonbar-xft port. The two can be
merged later if appropriate. Just decide whether to rename files so they
can be installed alongside each other, or mark the conflict.

Please don't use _ in the package version though.



Re: Patch to enable XFT on lemonbar

2019-02-15 Thread Peter Hessler
On 2019 Feb 08 (Fri) at 20:34:00 +0100 (+0100), Ingo Feinerer wrote:
:On Fri, Nov 23, 2018 at 05:41:09PM +0100, Ingo Feinerer wrote:
:> Brian Callahan wrote:
:> > Joel Carnat wrote:
:> > > On a journey to find a statusbar for cwm, I found that x11/lemonbar
:> > > didn't support XFT. I used sources from https://github.com/krypt-n/bar
:> > > to compile on OpenBSD 6.4/amd64 and it seems to work. So far, it
:> > > compiles, lemonbar starts and renders text using xft:Sans:size=11.
:> 
:> Thanks for investigating and preparing a patch!
:> 
:> > This would additionally need a REVISION bump in the port Makefile.
:> > But this seems rather large and invasive.
:> 
:> I agree that this patch is quite invasive.
:> 
:> > That's not a "no" in and of itself, but would it make more sense to
:> > send this upstream
:> 
:> Since there is a issue (https://github.com/LemonBoy/bar/issues/188) from
:> Aug 5, 2016 with no progress I do not think that this has good chances.
:> But who knows ...
:> 
:> > or perhaps switch to that forked repo with this already included?
:> 
:> I think that is the way to go. The few commits in LemonBoy/bar in the
:> last two years are mainly of cosmetic nature (see GitHub history), so
:> the forked repo has the original and new functionality.
:
:A few days later ...
:
:Here is a diff that switches lemonbar to the krypt-n/bar fork supporting
:XFT. A tarball is attached for two patches (I wanted to avoid `cvs add`
:on the patches directory). The inline diff just shows the changes to the
:Makefile and distinfo.
:
:At the same time add pledge() before the main processing loop. It is
:nice to see that "stdio" is enough at this point (after initialization
:which needed at least "rpath" is my tests; likely for loading some
:fonts).
:
:Alternatively we could create a new port for the fork (e.g.,
:lemonbar-xft). But since both LemonBoy/bar and krypt-n/bar have not seen
:a lot of changes recently we won't miss anything important if we just
:switch.
:

I tried running it, but it kept puking on my existing scripts.

Also, this branch is quite a few commits behind the existing one.

I'd *much* rather we not change the upstream.  Either a new port or the
big invasive patch.  Considering how inactive both projects are,
carrying a patch isn't completely terrible :/.


:So OK for the switch?
:
:Best regards,
:Ingo
:
:Index: Makefile
:===
:RCS file: /cvs/ports/x11/lemonbar/Makefile,v
:retrieving revision 1.5
:diff -u -p -r1.5 Makefile
:--- Makefile   21 Nov 2017 06:08:37 -  1.5
:+++ Makefile   8 Feb 2019 18:52:54 -
:@@ -2,13 +2,14 @@
: 
: COMMENT = featherweight lemon-scented bar
: 
:-VERSION = 1.3
:+VERSION = 1.1_20180416
:+EPOCH =   0
: 
:-PKGNAME = lemonbar-${VERSION}
:+DISTNAME =lemonbar-${VERSION}
: 
:-GH_ACCOUNT =  LemonBoy
:+GH_ACCOUNT =  krypt-n
: GH_PROJECT =  bar
:-GH_TAGNAME =  v${VERSION}
:+GH_COMMIT =   00a3fe6f3485203896156480e86014136749a221
: 
: CATEGORIES =  x11
: 
:@@ -17,7 +18,9 @@ MAINTAINER = Ingo Feinerer 

Re: Patch to enable XFT on lemonbar

2019-02-13 Thread Ingo Feinerer
Any dev willing to OK this?
https://marc.info/?l=openbsd-ports&m=154965459115588&w=2
(As it switches upstream and uses EPOCH I would appreciate another pair
of eyes).

I've got a positive test report so far and have been running this
pledged version since a few days without problems.

On Fri, Feb 08, 2019 at 08:34:00PM +0100, Ingo Feinerer wrote:
> Here is a diff that switches lemonbar to the krypt-n/bar fork supporting
> XFT. A tarball is attached for two patches (I wanted to avoid `cvs add`
> on the patches directory). The inline diff just shows the changes to the
> Makefile and distinfo.
> 
> At the same time add pledge() before the main processing loop. It is
> nice to see that "stdio" is enough at this point (after initialization
> which needed at least "rpath" is my tests; likely for loading some
> fonts).
> 
> Alternatively we could create a new port for the fork (e.g.,
> lemonbar-xft). But since both LemonBoy/bar and krypt-n/bar have not seen
> a lot of changes recently we won't miss anything important if we just
> switch.
> 
> So OK for the switch?



Re: Patch to enable Xft on lemonbar

2019-02-11 Thread Tom Murphy
Hi Ingo,

  Apologies, I didn't see the tarball until it was too late,
  so I untarred that and it compiles and runs fine here. No
  changes needed to the Makefile.

  (Sorry for getting your name wrong in the previous email's
  To: line.. bad muscle memory typing things!)

  I am really liking this new Xft-enabled lemonbar. The fonts
  are so much nicer now.

  Thanks for this!

  Kind regards,
  Tom



Re: Patch to enable XFT on lemonbar

2019-02-11 Thread Tom Murphy
Hi Ingo,

>A few days later ...
>
>Here is a diff that switches lemonbar to the krypt-n/bar fork supporting
>XFT. A tarball is attached for two patches (I wanted to avoid `cvs add`
>on the patches directory). The inline diff just shows the changes to the
>Makefile and distinfo.
>
>At the same time add pledge() before the main processing loop. It is
>nice to see that "stdio" is enough at this point (after initialization
>which needed at least "rpath" is my tests; likely for loading some
>fonts).
>
>Alternatively we could create a new port for the fork (e.g.,
>lemonbar-xft). But since both LemonBoy/bar and krypt-n/bar have not seen
>a lot of changes recently we won't miss anything important if we just
>switch.
>
>So OK for the switch?
>
>Best regards,
>Ingo

I've been looking for the Xft version of lemonbar in ports lately
too, however I couldn't get it to compile with your patch.

I had to amend CFLAGS in the Makefile like so:

CFLAGS +=   -I${X11BASE}/include \
-I${X11BASE}/include/freetype2

Without it, I got fatal errors building:

/usr/X11R6/include/X11/Xft/Xft.h:39:10: fatal error: 'ft2build.h' 
file not found

Other than that, it built with the CFLAGS changes above and
works for me with Xft fonts.

Thanks,
Tom



Re: Patch to enable XFT on lemonbar

2019-02-08 Thread Ingo Feinerer
On Fri, Nov 23, 2018 at 05:41:09PM +0100, Ingo Feinerer wrote:
> Brian Callahan wrote:
> > Joel Carnat wrote:
> > > On a journey to find a statusbar for cwm, I found that x11/lemonbar
> > > didn't support XFT. I used sources from https://github.com/krypt-n/bar
> > > to compile on OpenBSD 6.4/amd64 and it seems to work. So far, it
> > > compiles, lemonbar starts and renders text using xft:Sans:size=11.
> 
> Thanks for investigating and preparing a patch!
> 
> > This would additionally need a REVISION bump in the port Makefile.
> > But this seems rather large and invasive.
> 
> I agree that this patch is quite invasive.
> 
> > That's not a "no" in and of itself, but would it make more sense to
> > send this upstream
> 
> Since there is a issue (https://github.com/LemonBoy/bar/issues/188) from
> Aug 5, 2016 with no progress I do not think that this has good chances.
> But who knows ...
> 
> > or perhaps switch to that forked repo with this already included?
> 
> I think that is the way to go. The few commits in LemonBoy/bar in the
> last two years are mainly of cosmetic nature (see GitHub history), so
> the forked repo has the original and new functionality.

A few days later ...

Here is a diff that switches lemonbar to the krypt-n/bar fork supporting
XFT. A tarball is attached for two patches (I wanted to avoid `cvs add`
on the patches directory). The inline diff just shows the changes to the
Makefile and distinfo.

At the same time add pledge() before the main processing loop. It is
nice to see that "stdio" is enough at this point (after initialization
which needed at least "rpath" is my tests; likely for loading some
fonts).

Alternatively we could create a new port for the fork (e.g.,
lemonbar-xft). But since both LemonBoy/bar and krypt-n/bar have not seen
a lot of changes recently we won't miss anything important if we just
switch.

So OK for the switch?

Best regards,
Ingo

Index: Makefile
===
RCS file: /cvs/ports/x11/lemonbar/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile21 Nov 2017 06:08:37 -  1.5
+++ Makefile8 Feb 2019 18:52:54 -
@@ -2,13 +2,14 @@
 
 COMMENT =  featherweight lemon-scented bar
 
-VERSION =  1.3
+VERSION =  1.1_20180416
+EPOCH =0
 
-PKGNAME =  lemonbar-${VERSION}
+DISTNAME = lemonbar-${VERSION}
 
-GH_ACCOUNT =   LemonBoy
+GH_ACCOUNT =   krypt-n
 GH_PROJECT =   bar
-GH_TAGNAME =   v${VERSION}
+GH_COMMIT =00a3fe6f3485203896156480e86014136749a221
 
 CATEGORIES =   x11
 
@@ -17,7 +18,9 @@ MAINTAINER =  Ingo Feinerer 

lemonbar.tar.gz
Description: application/tar-gz


Re: Patch to enable XFT on lemonbar

2018-11-24 Thread Joel Carnat
Hi,

On Fri 23 Nov 17:41, Ingo Feinerer wrote:
> Brian Callahan wrote:
> > Joel Carnat wrote:
> > > On a journey to find a statusbar for cwm, I found that x11/lemonbar
> > > didn't support XFT. I used sources from https://github.com/krypt-n/bar
> > > to compile on OpenBSD 6.4/amd64 and it seems to work. So far, it
> > > compiles, lemonbar starts and renders text using xft:Sans:size=11.
> 
> Thanks for investigating and preparing a patch!
> 
> > This would additionally need a REVISION bump in the port Makefile.
> > But this seems rather large and invasive.
> 
> I agree that this patch is quite invasive.
> 
> > That's not a "no" in and of itself, but would it make more sense to
> > send this upstream
> 
> Since there is a issue (https://github.com/LemonBoy/bar/issues/188) from
> Aug 5, 2016 with no progress I do not think that this has good chances.
> But who knows ...
> 
> > or perhaps switch to that forked repo with this already included?
> 
> I think that is the way to go. The few commits in LemonBoy/bar in the
> last two years are mainly of cosmetic nature (see GitHub history), so
> the forked repo has the original and new functionality.
> 
> @Joel: would you like to prepare a diff for switching? You could also
> take maintainer at this occasion if you are willing to take care of this
> port.
> 

I'm not sure yet that I'm going to use it :) As I said, I'm looking at
various options ; from window managers to utilities. So I won't be able
to take maintainer on it. I'm also investigating into suckless stuff.

That said, I can have a look at the other repo and see if I can manage
to modify x11/lemonbar/Makefile to use it.

Regards,
  Jo



Re: Patch to enable XFT on lemonbar

2018-11-23 Thread Ingo Feinerer
Brian Callahan wrote:
> Joel Carnat wrote:
> > On a journey to find a statusbar for cwm, I found that x11/lemonbar
> > didn't support XFT. I used sources from https://github.com/krypt-n/bar
> > to compile on OpenBSD 6.4/amd64 and it seems to work. So far, it
> > compiles, lemonbar starts and renders text using xft:Sans:size=11.

Thanks for investigating and preparing a patch!

> This would additionally need a REVISION bump in the port Makefile.
> But this seems rather large and invasive.

I agree that this patch is quite invasive.

> That's not a "no" in and of itself, but would it make more sense to
> send this upstream

Since there is a issue (https://github.com/LemonBoy/bar/issues/188) from
Aug 5, 2016 with no progress I do not think that this has good chances.
But who knows ...

> or perhaps switch to that forked repo with this already included?

I think that is the way to go. The few commits in LemonBoy/bar in the
last two years are mainly of cosmetic nature (see GitHub history), so
the forked repo has the original and new functionality.

@Joel: would you like to prepare a diff for switching? You could also
take maintainer at this occasion if you are willing to take care of this
port.

Best regards,
Ingo



Re: Patch to enable XFT on lemonbar

2018-11-23 Thread Brian Callahan

Hi Joel --

On 11/22/18 6:53 PM, Joel Carnat wrote:

Hi,

On a journey to find a statusbar for cwm, I found that x11/lemonbar
didn't support XFT. I used sources from https://github.com/krypt-n/bar
to compile on OpenBSD 6.4/amd64 and it seems to work. So far, it
compiles, lemonbar starts and renders text using xft:Sans:size=11.

Find the relevant patches attached.

Regards,
   Jo



This would additionally need a REVISION bump in the port Makefile.
But this seems rather large and invasive. That's not a "no" in and of 
itself, but would it make more sense to send this upstream, or perhaps 
switch to that forked repo with this already included?


~Brian



Re: Patch to enable XFT on lemonbar

2018-11-23 Thread Jeremie Courreges-Anglas
On Fri, Nov 23 2018, Joel Carnat  wrote:
> Hi,

Hi,

> On a journey to find a statusbar for cwm, I found that x11/lemonbar
> didn't support XFT. I used sources from https://github.com/krypt-n/bar
> to compile on OpenBSD 6.4/amd64 and it seems to work. So far, it
> compiles, lemonbar starts and renders text using xft:Sans:size=11.
>
> Find the relevant patches attached.

Make sure you at least Cc the port maintainer.  You should probably have
discussed this diff with Ingo first, it looks a bit intrusive.

> Regards,
>   Jo
>
> --- Makefile.orig Fri Nov 23 00:26:08 2018
> +++ Makefile  Fri Nov 23 00:35:00 2018
> @@ -1,4 +1,4 @@
>  # This snippet has been shmelessly stol^Hborrowed from thestinger's repose 
> Makefile
> -VERSION = 1.2
> +VERSION = 1.3
>  GIT_DESC=$(shell test -d .git && git describe --always 2>/dev/null)
>  
> @@ -8,6 +8,8 @@
>  
>  CC   ?= gcc
> -CFLAGS += -Wall -std=c99 -DVERSION="\"$(VERSION)\""
> -LDFLAGS += -lxcb -lxcb-xinerama -lxcb-randr
> +CFLAGS += -Wall -std=c99 -DVERSION="\"$(VERSION)\"" \
> + -I/usr/X11R6/include/freetype2
> +LDFLAGS += -lxcb -lxcb-xinerama -lxcb-randr \
> +  -lX11 -lX11-xcb -lXft -lfreetype -lz 
> -lfontconfig
>  CFDEBUG = -g3 -pedantic -Wall -Wunused-parameter -Wlong-long \
>-Wsign-conversion -Wconversion -Wimplicit-function-declaration
>
> --- lemonbar.c.orig   Mon Nov 20 11:47:43 2017
> +++ lemonbar.cFri Nov 23 00:30:26 2018
> @@ -2,4 +2,5 @@
>  #define _POSIX_C_SOURCE 200809L
>  #include 
> +#include 
>  #include 
>  #include 
> @@ -8,4 +9,5 @@
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> @@ -18,6 +20,9 @@
>  #include 
>  
> -// Here be dragons
> +#include 
> +#include 
>  
> +// Here bet  dragons
> +
>  #define max(a,b) ((a) > (b) ? (a) : (b))
>  #define min(a,b) ((a) < (b) ? (a) : (b))
> @@ -26,8 +31,13 @@
>  typedef struct font_t {
>  xcb_font_t ptr;
> +xcb_charinfo_t *width_lut;
> +
> +XftFont *xft_ft;
> +
> +int ascent;
> +
>  int descent, height, width;
>  uint16_t char_max;
>  uint16_t char_min;
> -xcb_charinfo_t *width_lut;
>  } font_t;
>  
> @@ -69,9 +79,8 @@
>  };
>  
> -enum {
> -ALIGN_L = 0,
> -ALIGN_C,
> -ALIGN_R
> -};
> +enum { ALIGN_L = 0,
> +   ALIGN_C,
> +   ALIGN_R
> + };
>  
>  enum {
> @@ -84,13 +93,24 @@
>  #define MAX_FONT_COUNT 5
>  
> +static Display *dpy;
>  static xcb_connection_t *c;
> +
>  static xcb_screen_t *scr;
> +static int scr_nbr = 0;
> +
>  static xcb_gcontext_t gc[GC_MAX];
>  static xcb_visualid_t visual;
> +static Visual *visual_ptr;
>  static xcb_colormap_t colormap;
> +
> +
>  static monitor_t *monhead, *montail;
>  static font_t *font_list[MAX_FONT_COUNT];
>  static int font_count = 0;
>  static int font_index = -1;
> +static int offsets_y[MAX_FONT_COUNT];
> +static int offset_y_count = 0;
> +static int offset_y_index = 0;
> +
>  static uint32_t attrs = 0;
>  static bool dock = false;
> @@ -102,4 +122,12 @@
>  static area_stack_t area_stack;
>  
> +static XftColor sel_fg;
> +static XftDraw *xft_draw;
> +
> +//char width lookuptable
> +#define MAX_WIDTHS (1 << 16)
> +static wchar_t xft_char[MAX_WIDTHS];
> +static charxft_width[MAX_WIDTHS];
> +
>  void
>  update_gc (void)
> @@ -108,4 +136,11 @@
>  xcb_change_gc(c, gc[GC_CLEAR], XCB_GC_FOREGROUND, (const uint32_t []){ 
> bgc.v });
>  xcb_change_gc(c, gc[GC_ATTR], XCB_GC_FOREGROUND, (const uint32_t []){ 
> ugc.v });
> +XftColorFree(dpy, visual_ptr, colormap , &sel_fg);
> +char color[] = "#ff";
> +uint32_t nfgc = fgc.v & 0x00ff;
> +snprintf(color, sizeof(color), "#%06X", nfgc);
> +if (!XftColorAllocName (dpy, visual_ptr, colormap, color, &sel_fg)) {
> +fprintf(stderr, "Couldn't allocate xft font color '%s'\n", color);
> +}
>  }
>  
> @@ -189,5 +224,35 @@
>  }
>  
> +
>  int
> +xft_char_width_slot (uint16_t ch)
> +{
> +int slot = ch % MAX_WIDTHS;
> +while (xft_char[slot] != 0 && xft_char[slot] != ch)
> +{
> +slot = (slot + 1) % MAX_WIDTHS;
> +}
> +return slot;
> +}
> +
> +int xft_char_width (uint16_t ch, font_t *cur_font)
> +{
> +int slot = xft_char_width_slot(ch);
> +if (!xft_char[slot]) {
> +XGlyphInfo gi;
> +FT_UInt glyph = XftCharIndex (dpy, cur_font->xft_ft, (FcChar32) ch);
> +XftFontLoadGlyphs (dpy, cur_font->xft_ft, FcFalse, &glyph, 1);
> +XftGlyphExtents (dpy, cur_font->xft_ft, &glyph, 1, &gi);
> +XftFontUnloadGlyphs (dpy, cur_font->xft_ft, &glyph, 1);
> +xft_char[slot] = ch;
> +xft_width[slot] = gi.xOff;
> +return gi.xOff;
> +} else if (xft_char[slot] == ch)
> +return xft_width[slot];
> +else
> +return 0;
> +}
> +
> +int
>  shift (monitor_t *mon, int x, int align, int ch_width)
>  {
> @@ -208,6 +273,6 @@
>  break;
>  }
> -
> -// Draw the background first
> +
> +/* Draw the background first */

Patch to enable XFT on lemonbar

2018-11-22 Thread Joel Carnat
Hi,

On a journey to find a statusbar for cwm, I found that x11/lemonbar
didn't support XFT. I used sources from https://github.com/krypt-n/bar
to compile on OpenBSD 6.4/amd64 and it seems to work. So far, it
compiles, lemonbar starts and renders text using xft:Sans:size=11.

Find the relevant patches attached.

Regards,
  Jo

--- Makefile.orig   Fri Nov 23 00:26:08 2018
+++ MakefileFri Nov 23 00:35:00 2018
@@ -1,4 +1,4 @@
 # This snippet has been shmelessly stol^Hborrowed from thestinger's repose 
Makefile
-VERSION = 1.2
+VERSION = 1.3
 GIT_DESC=$(shell test -d .git && git describe --always 2>/dev/null)
 
@@ -8,6 +8,8 @@
 
 CC ?= gcc
-CFLAGS += -Wall -std=c99 -DVERSION="\"$(VERSION)\""
-LDFLAGS += -lxcb -lxcb-xinerama -lxcb-randr
+CFLAGS += -Wall -std=c99 -DVERSION="\"$(VERSION)\"" \
+   -I/usr/X11R6/include/freetype2
+LDFLAGS += -lxcb -lxcb-xinerama -lxcb-randr \
+-lX11 -lX11-xcb -lXft -lfreetype -lz 
-lfontconfig
 CFDEBUG = -g3 -pedantic -Wall -Wunused-parameter -Wlong-long \
   -Wsign-conversion -Wconversion -Wimplicit-function-declaration
--- lemonbar.c.orig Mon Nov 20 11:47:43 2017
+++ lemonbar.c  Fri Nov 23 00:30:26 2018
@@ -2,4 +2,5 @@
 #define _POSIX_C_SOURCE 200809L
 #include 
+#include 
 #include 
 #include 
@@ -8,4 +9,5 @@
 #include 
 #include 
+#include 
 #include 
 #include 
@@ -18,6 +20,9 @@
 #include 
 
-// Here be dragons
+#include 
+#include 
 
+// Here bet  dragons
+
 #define max(a,b) ((a) > (b) ? (a) : (b))
 #define min(a,b) ((a) < (b) ? (a) : (b))
@@ -26,8 +31,13 @@
 typedef struct font_t {
 xcb_font_t ptr;
+xcb_charinfo_t *width_lut;
+
+XftFont *xft_ft;
+
+int ascent;
+
 int descent, height, width;
 uint16_t char_max;
 uint16_t char_min;
-xcb_charinfo_t *width_lut;
 } font_t;
 
@@ -69,9 +79,8 @@
 };
 
-enum {
-ALIGN_L = 0,
-ALIGN_C,
-ALIGN_R
-};
+enum { ALIGN_L = 0,
+   ALIGN_C,
+   ALIGN_R
+ };
 
 enum {
@@ -84,13 +93,24 @@
 #define MAX_FONT_COUNT 5
 
+static Display *dpy;
 static xcb_connection_t *c;
+
 static xcb_screen_t *scr;
+static int scr_nbr = 0;
+
 static xcb_gcontext_t gc[GC_MAX];
 static xcb_visualid_t visual;
+static Visual *visual_ptr;
 static xcb_colormap_t colormap;
+
+
 static monitor_t *monhead, *montail;
 static font_t *font_list[MAX_FONT_COUNT];
 static int font_count = 0;
 static int font_index = -1;
+static int offsets_y[MAX_FONT_COUNT];
+static int offset_y_count = 0;
+static int offset_y_index = 0;
+
 static uint32_t attrs = 0;
 static bool dock = false;
@@ -102,4 +122,12 @@
 static area_stack_t area_stack;
 
+static XftColor sel_fg;
+static XftDraw *xft_draw;
+
+//char width lookuptable
+#define MAX_WIDTHS (1 << 16)
+static wchar_t xft_char[MAX_WIDTHS];
+static charxft_width[MAX_WIDTHS];
+
 void
 update_gc (void)
@@ -108,4 +136,11 @@
 xcb_change_gc(c, gc[GC_CLEAR], XCB_GC_FOREGROUND, (const uint32_t []){ 
bgc.v });
 xcb_change_gc(c, gc[GC_ATTR], XCB_GC_FOREGROUND, (const uint32_t []){ 
ugc.v });
+XftColorFree(dpy, visual_ptr, colormap , &sel_fg);
+char color[] = "#ff";
+uint32_t nfgc = fgc.v & 0x00ff;
+snprintf(color, sizeof(color), "#%06X", nfgc);
+if (!XftColorAllocName (dpy, visual_ptr, colormap, color, &sel_fg)) {
+fprintf(stderr, "Couldn't allocate xft font color '%s'\n", color);
+}
 }
 
@@ -189,5 +224,35 @@
 }
 
+
 int
+xft_char_width_slot (uint16_t ch)
+{
+int slot = ch % MAX_WIDTHS;
+while (xft_char[slot] != 0 && xft_char[slot] != ch)
+{
+slot = (slot + 1) % MAX_WIDTHS;
+}
+return slot;
+}
+
+int xft_char_width (uint16_t ch, font_t *cur_font)
+{
+int slot = xft_char_width_slot(ch);
+if (!xft_char[slot]) {
+XGlyphInfo gi;
+FT_UInt glyph = XftCharIndex (dpy, cur_font->xft_ft, (FcChar32) ch);
+XftFontLoadGlyphs (dpy, cur_font->xft_ft, FcFalse, &glyph, 1);
+XftGlyphExtents (dpy, cur_font->xft_ft, &glyph, 1, &gi);
+XftFontUnloadGlyphs (dpy, cur_font->xft_ft, &glyph, 1);
+xft_char[slot] = ch;
+xft_width[slot] = gi.xOff;
+return gi.xOff;
+} else if (xft_char[slot] == ch)
+return xft_width[slot];
+else
+return 0;
+}
+
+int
 shift (monitor_t *mon, int x, int align, int ch_width)
 {
@@ -208,6 +273,6 @@
 break;
 }
-
-// Draw the background first
+
+/* Draw the background first */
 fill_rect(mon->pixmap, gc[GC_CLEAR], x, 0, ch_width, bh);
 return x;
@@ -234,17 +299,28 @@
 draw_char (monitor_t *mon, font_t *cur_font, int x, int align, uint16_t ch)
 {
-int ch_width = (cur_font->width_lut) ?
-cur_font->width_lut[ch - cur_font->char_min].character_width:
-cur_font->width;
+int ch_width;
 
+if (cur_font->xft_ft) {
+ch_width = xft_char_width(ch, cur_font);
+} else {
+ch_width = (cur_font->width_lut) ?
+cur_font->width_lut[ch - cur_font->char_min]