[dev] gtk3 support for surf?

[Markus Teich]

Heyho,

are there plans to port surf to gtk3, so it can be used under wayland?

--Markus

[Bryan Bennett]

Hey -
Check the smoothscroll patch[1]. Maybe this is what you want?

[1]: http://surf.suckless.org/patches/smoothscrolling

Bryan

[Sylvain BERTRAND]

It's a bit on the side of the topic but GTK+ is now hard
dependent through pango on harfbuzz, a c++ component (object
oriented cluster f....), which pulls a dependency on c++
compiler/runtime.

To safeguard netsurf from the toxic c++, a good thing would be to
be able to compile the entire user level stack of netsurf with a
C compiler like tinycc.

Another way to see thing would be to go to EFL. After discussing
that with the EFL developer in charge, the EFL text layout engine
can be set to use harfbuzz or a internal basic one. But the
developer strongly suggested that it may become hard dependant on
harfbuzz in the end. Then better stick with GTK+, since at least
it's protected with a GNU (L)GPL license, then GTK+3 support
would make sense.

Since a unicode text layout engine is very important for a
international browser, and since the C toolkits are delegating
that task to a c++ component... what to do? Because, netsurf
being the only C coded javascript www browser out there, in my
humble opinion, it's important to safeguard this feature.

Personnally, I did a very partial C port of harfbuzz in C,
https://code.google.com/p/charfbuzz/ , which is a drop in
remplacement of harfbuzz (C api). I already mentioned it several
times on this mailing list. I'm not working on it right now (I'm
on an alternative linux radeon driver), but I will probably come
back to unroll the original c++ code in C in the futur.

regards,

--
Sylvain

[Markus Teich]

Sylvain BERTRAND wrote:
> It's a bit on the side of the topic but GTK+ is now hard dependent through
> pango on harfbuzz, a c++ component (object oriented cluster f....), which
> pulls a dependency on c++ compiler/runtime.

WebKitGTK is also written in C++ so we need a C++ compiler and runtime anyway.

> To safeguard netsurf from the toxic c++, a good thing would be to be able to
> compile the entire user level stack of netsurf with a C compiler like tinycc.

I am confused. Are you talking about NetSurf [0] or surf [1]?

> Another way to see thing would be to go to EFL. After discussing that with the
> EFL developer in charge, the EFL text layout engine can be set to use harfbuzz
> or a internal basic one. But the developer strongly suggested that it may
> become hard dependant on harfbuzz in the end. Then better stick with GTK+,
> since at least it's protected with a GNU (L)GPL license, then GTK+3 support
> would make sense.

I don't see how EFL can be used as or with a website layout engine. Could you
elaborate on that?

> Since a unicode text layout engine is very important for a international
> browser, and since the C toolkits are delegating that task to a c++
> component... what to do? Because, netsurf being the only C coded javascript
> www browser out there, in my humble opinion, it's important to safeguard this
> feature.

The NetSurf I mentioned above actually only has experimental js support.

> Personnally, I did a very partial C port of harfbuzz in C,
> https://code.google.com/p/charfbuzz/ , which is a drop in remplacement of
> harfbuzz (C api). I already mentioned it several times on this mailing list.
> I'm not working on it right now (I'm on an alternative linux radeon driver),
> but I will probably come back to unroll the original c++ code in C in the
> futur.

I don't think a port to C would work out well. If the code is as bad as you
claim, a clean rewrite should take less time and lead to a better result.

--Markus

[Markus Teich]

Bryan Bennett wrote:
> Check the smoothscroll patch[1]. Maybe this is what you want?
>
> [1]: http://surf.suckless.org/patches/smoothscrolling

Thank you. I would have never found this by just looking for gtk3. I'll try it
soon.

--Markus

[Markus Teich]

Markus Teich wrote:
> I am confused. Are you talking about NetSurf [0] or surf [1]?

And here are the links I knew I would forget…

[0]: https://www.netsurf-browser.org/
[1]: http://surf.suckless.org/

[Christoph Lohmann]

Greetings.

On Fri, 10 Jan 2014 17:35:18 +0100 Markus Teich <markus...@stusta.mhn.de> wrote:
> Heyho,
>
> are there plans to port surf to gtk3, so it can be used under wayland?

That would be the first argument to support GTK3, if that’s the only way
to make it work under Wayland.

Since surf is just a userinterface to a huge bloated background I don’t
care about which libraries are used as dependency. That web crap is al‐
ready pulling in nearly the whole software industry.

In a broader perspective surf is the access interface for the suckless
world to this the‐web‐is‐the‐interface‐to‐everything software environ‐
ment. And it’s good at that.

The current speed of the web changes and the growth in suckless develop‐
ment resources correlate that we will never take over the web. In con‐
clusion: as long as this isn’t solved, a hard dependency on crap li‐
braries is given.

Are there any arguments against switching to GTK3? Otherwise I will
switch surf to GTK3 using the smootscrolling patch.


Sincerely,

Christoph Lohmann

[Bobby Powers]

Hello,

Christoph Lohmann wrote:
> Are there any arguments against switching to GTK3? Otherwise I will
> switch surf to GTK3 using the smootscrolling patch.

GTK3's Windows support is pretty new and not as well tested.


yours in sarcasm,
Bobby

[FRIGN]

On Fri, 10 Jan 2014 17:35:18 +0100
Christoph Lohmann <2...@r-36.net> wrote:

> That web crap is al‐
> ready pulling in nearly the whole software industry.

Thanks, Christoph; you made my day!

> Are there any arguments against switching to GTK3? Otherwise I will
> switch surf to GTK3 using the smootscrolling patch.

Well, maybe that GTK3-programs suck? They feel very slow imho and don't fit
well into a world where GTK2 is still the least-painful way to go.

Looking at it in relativity to Wayland: Let's be honest; who's already
using Wayland today? Weston is a bloated POS and I've just begun work
on writing a dwm wayland-compositor, which is definitely not an easy
job.
I am sure the few people already using Wayland will be smart enough to
just pull in the external GTK3-patch and be fine.

But please: Don't force this crap on everyone else, too!

Best regards

FRIGN

--
FRIGN <d...@frign.de>

[Markus Teich]

FRIGN wrote:
> Looking at it in relativity to Wayland: Let's be honest; who's already using
> Wayland today?

I would like to. I already tested weston and it works fine so far in the sense
of drawing fancy rotating things, simulated smoke and flowers - the usual things
you would expect from a window manager. However I miss the following pieces for
a productive working environment:

* dwm
* browser (surf)
* st (there is a patchset, which I'll try to adapt to my tree soon)

> Weston is a bloated POS and I've just begun work on writing a dwm
> wayland-compositor, which is definitely not an easy job.

If I can, I would like to help. Where is the code hosted? I also found swc[0]
written by the same guy who wrote the st port to wayland. However I feel it is
not really as simple as it claims to be.

> I am sure the few people already using Wayland will be smart enough to just
> pull in the external GTK3-patch and be fine.
>
> But please: Don't force this crap on everyone else, too!

I would be fine with this.

--Markus

[0]: https://github.com/michaelforney/swc

[FRIGN]

On Fri, 10 Jan 2014 18:49:13 +0100
Markus Teich <markus...@stusta.mhn.de> wrote:

> If I can, I would like to help. Where is the code hosted? I also found swc[0]
> written by the same guy who wrote the st port to wayland. However I feel it is
> not really as simple as it claims to be.

The code is hosted here[1].
Thanks for linking me to swc! I'll check it out and combine it with my
ideas. There really is a lot of code in that library!

I'll definitely give you guys an update on my status, but I'm sure
there should be a way to write a simple tiling-wm in less than 5k SLOC.

Cheers

FRIGN

[1]: http://frign.brain/ No seriously, I have it all written on paper
here. I'll host it somewhere once it has raw functionality ;).
I could definitely use some help, implementing a wl-compositor is
not a trivial task for sure! Thanks for the offer!
--
FRIGN <d...@frign.de>

[Markus Teich]

FRIGN wrote:
> I'll definitely give you guys an update on my status, but I'm sure there
> should be a way to write a simple tiling-wm in less than 5k SLOC.

Some random idea:
Have you thought about weston-launch yet? It's a wrapper suid-binary getting all
necessary resources and forking the real weston afterwards. I think it can be
done in one suid binary dropping priviledges after it got all relevant
resources.

--Markus

[FRIGN]

On Fri, 10 Jan 2014 19:19:48 +0100
Markus Teich <markus...@stusta.mhn.de> wrote:

> Some random idea:
> Have you thought about weston-launch yet? It's a wrapper suid-binary getting all
> necessary resources and forking the real weston afterwards. I think it can be
> done in one suid binary dropping priviledges after it got all relevant
> resources.

Weston has a hard-dependency on PAM. Nuff said.

Cheers

FRIGN

--
FRIGN <d...@frign.de>

[Sylvain BERTRAND]

Ooops! I read netsurf all along. My bad.

--
Sylvain

[Michael Forney]

Hi,

On Fri, 10 Jan 2014 17:05:17 +0100, FRIGN <d...@frign.de> wrote:
> On Fri, 10 Jan 2014 18:49:13 +0100
> Markus Teich <markus...@stusta.mhn.de> wrote:
>
> > If I can, I would like to help. Where is the code hosted? I also found swc[0]
> > written by the same guy who wrote the st port to wayland. However I feel it is
> > not really as simple as it claims to be.
>
> The code is hosted here[1].
> Thanks for linking me to swc! I'll check it out and combine it with my
> ideas. There really is a lot of code in that library!

I'm glad others are interested in this! In response to your comments
about it being a lot of code: writing a display server turns out to be a
lot of work, which I'm sure you will discover for yourself :) Although
perhaps it appears larger than it is; I tend to prefer working with many
small files instead of several large ones. While there are a lot of
source files, my current working tree sits at < 6k SLOC. Additionally, I
am quite open to suggestions about how certain portions could be
simplified or done differently.

I am definitely interested in combining efforts/ideas if possible. I've
been working on this off and on for about a year now, and I have learned
a lot in that time. Feel free to use swc as a reference for your project
if you want (I do believe it to be quite a bit simpler than weston).

Perhaps the biggest obstacle I've come across is how to do rendering in
a simple and efficient way, yet retain hardware support. I opted to
create a very primitive drawing library (which is also used by my st and
dmenu ports), which I am currently in the middle of a major refactor. It
currently only supports software and intel hardware rendering. There is
of course OpenGL, and while it will most likely be available on the
majority of systems, it is fairly heavyweight for the job.

> I'll definitely give you guys an update on my status, but I'm sure
> there should be a way to write a simple tiling-wm in less than 5k SLOC.

I'm of the opinion that the compositor and window manager should be
separate projects, which is why I implemented swc as a library. Look at
the number of tiling X11 window managers out there. It doesn't make
sense to have each of them implement their own compositing code.

Please let me know if you have any questions! I would be happy to help!

--
Michael Forney <mfo...@mforney.org>

[FRIGN]

On Sat, 11 Jan 2014 01:38:13 +0000
Michael Forney <mfo...@mforney.org> wrote:

> I'm of the opinion that the compositor and window manager should be
> separate projects, which is why I implemented swc as a library. Look at
> the number of tiling X11 window managers out there. It doesn't make
> sense to have each of them implement their own compositing code.
>
> Please let me know if you have any questions! I would be happy to help!

Hey Michael,

I read your swc-code yesterday and must say that it is pretty lean,
considering its feature-set.
The next step may be to write a basic compositor atop swc, implement
dwm functionality and then probably discuss which features in swc we
might not need (it being a well-separated library makes exclusion very
comfortable!).
I must say I wronged you in regard to code-volume and should've looked
at it a bit more before giving this remark.

[Dmitrij D. Czarkoff]

FRIGN said:
> Well, maybe that GTK3-programs suck? They feel very slow imho and don't fit
> well into a world where GTK2 is still the least-painful way to go.

At least on OpenBSD GTK+3 is already required for GTK+2 webkit:

/usr/ports/www/surf $ make full-run-depends | grep gtk
gtk-update-icon-cache-2.24.22
gtk+3-3.10.6
gtk+2-2.24.22p0

This makes the whole point of "GTK+3 is bad" a bit moot here from
practical standpoint. AFAIK webkit2 (GTK+3 version) is also a bit ahead
of webkit1 feature-wise, which may be important, specificly given that
surf is indeed an interface to things that already suck big time.

--
Dmitrij D. Czarkoff

[Silvan Jegen]

Hi

On Sat, Jan 11, 2014 at 09:43:44AM +0100, FRIGN wrote:
> On Sat, 11 Jan 2014 01:38:13 +0000
> Michael Forney <mfo...@mforney.org> wrote:
>
> > I'm of the opinion that the compositor and window manager should be
> > separate projects, which is why I implemented swc as a library. Look at
> > the number of tiling X11 window managers out there. It doesn't make
> > sense to have each of them implement their own compositing code.
> >
> > Please let me know if you have any questions! I would be happy to help!
>
> Hey Michael,
>
> I read your swc-code yesterday and must say that it is pretty lean,
> considering its feature-set.
> The next step may be to write a basic compositor atop swc, implement
> dwm functionality and then probably discuss which features in swc we
> might not need (it being a well-separated library makes exclusion very
> comfortable!).

st and dwm on Wayland is something I would love to see, if only to
get a glimpse of the functionality of the Wayland protocol and the
Wayland/client interactions.

I am just wondering how you would handle the window decorations? The
Wayland protocol seems to leave it unspecified whether a client has
to draw them themselves or whether the server has to do that[1]. If
that's the case, a Wayland-based dwm implementation cannot directly
control whether client decorations are drawn or not.

I remember reading a discussion about a way to tell Wayland clients
whether they should draw decorations themselves or not but I do not
remember where I read it (maybe the Wayland ML?) or if the participants
actually reached a generally accepted solution in the end...


Cheers,

Silvan


[1] http://blog.martin-graesslin.com/blog/2013/02/client-side-window-decorations-and-wayland/

[FRIGN]

On Sun, 12 Jan 2014 13:07:34 +0100
Silvan Jegen <s.j...@gmail.com> wrote:

> st and dwm on Wayland is something I would love to see, if only to
> get a glimpse of the functionality of the Wayland protocol and the
> Wayland/client interactions.

Hey Silvan,

I am still wondering if Wayland really is the way to go, given the fact
it requires a lot of dependencies for "basic" tasks (*(E)GL, dbus, PAM,
DRI (mostly)) and hogs memory.
Recently, I had a very interesting conversation with idunham[1], who is
currently working on tinyxlib[2] and tinyxserver[3], dramatically
cleaned-up versions of Xlib and Xserver linked against musl with
backported security-patches.
You might want to check it out after reading the forum-discussion!

Cheers

FRIGN

[1]: <http://phoronix.com/forums/showthread.php?93926-The-Tiny-X-Server-Fork-Is-Still-Being-Maintained&p=388106#post388106>
[2]: <https://github.com/idunham/tinyxlib>
[3]: <https://github.com/idunham/tinyxserver>

--
FRIGN <d...@frign.de>

[Nick]

> > Well, maybe that GTK3-programs suck? They feel very slow imho and don't fit
> > well into a world where GTK2 is still the least-painful way to go.
>
> At least on OpenBSD GTK+3 is already required for GTK+2 webkit:

surf is an interface to a world of suck, so keeping up to date with
whatever crappy libraries are most in vogue seems the most
reasonable thing to do. Arguments that GTK3 is worse than GTK2 are
irrelevant really, they both suck to the extreme, I don't care
whether one has 10% extra suck, they're both essentially intolerable
on that level. So yes, choose whichever upstream prefer, we're
totally beholden to them anyway.

> The current speed of the web changes and the growth in suckless develop‐
> ment resources correlate that we will never take over the web. In con‐
> clusion: as long as this isn’t solved, a hard dependency on crap li‐
> braries is given.

The WebkitNix project I mentioned here a while ago would minimise
our dependency on crap, but it would take more time than I have at
present to wrap a surf-like interface around it, and I haven't
checked whether it's usably buildable and stable yet (though I
suspect it is).

I just try to ignore the web as much as possible now. In general I
find it just disheartens me. I use pandoc or w3m -dump with my
tkread script[0] where I can, but it looks like surf or something
like it will continue to be necessary for many things for a long
time to come. May God have mercy upon us all.


0. git clone http://git.njw.me.uk/tkread.git

[Fernando C.V.]

On Sun, Jan 12, 2014 at 11:39 AM, FRIGN <d...@frign.de> wrote:
> I am still wondering if Wayland really is the way to go, given the fact
> it requires a lot of dependencies for "basic" tasks (*(E)GL, dbus, PAM,
> DRI (mostly)) and hogs memory.

I believe most of the implementation details are up to the compositor,
Wayland is just a protocol.

At least in archlinux, the wayland package has only 2 dependencies:
libffi and expat

Regards,
--
Fernando

[FRIGN]

On Tue, 14 Jan 2014 02:40:36 +0100
"Fernando C.V." <fer...@gmail.com> wrote:

Hi Fernando,

> I believe most of the implementation details are up to the compositor,
> Wayland is just a protocol.
> At least in archlinux, the wayland package has only 2 dependencies:
> libffi and expat

Yes, that's true. However, you need to stress here that Wayland is just
the protocol implementation for communication between clients and
server and glue-code between clients and EGL-calls.
It doesn't pull in the big libs itself, but _implicates_ a compositor
(server) using EGL to communicate with Mesa 3D.
On the client side, same applies.

You can't do Wayland without EGL.

Now, where's the problem?

-1) Compositor's demands:
Not everyone has a full drm-kms-setup. Hell, I don't even use evdev
on my devices (It's more secure when you strip out the Event Interface
from the Kernel).
The biggest factor here probably is Mesa 3D. You just don't want this
overhead if you don't intend to spend most of your time playing around
with 3D-effects and burning windows.
Given the direction the mainstream-Linux-desktop is going, Wayland is
the appropriate answer.

However, having looked into the topic a bit deeper, I basically found
the Wayland-Compositor-Client model to be very similar to what you get
implementing a GUI into a video-game[1] combined with several
util-functions to set _basic_ things up.

Yeah, I know Wayland doesn't require OpenGL(ES), but guess what most
compositors build upon.

-2) Code-rot:
The Wayland protocol itself may be very lean, but that's not where the
big overhead comes from. It rather is the fact you need to rewrite
trivial features like evdev for each new compositor you chose to
develop.
I know, there are libs, but who guarantees they're still around in a
few years _and_ compatible with the still rather "dynamic" Wayland-API?
Why not just write a Weston-plugin then? Because Weston sucks (PAM,
overengineered, too many features for dwm, ...)!
In the end, you just give up and implement it yourself, forcing you to
maintain thousands of LOC, risking bugs and wasting your time.

-3) Window decorations:
It was noted before, but window decorations are not trivial with
Wayland.
There's no problem with forcing the clients to shut up and just take
the borders the compositor tells them to take (afaik).
However, Weston is a liberal scumbag allowing the clients to to
whatever they want. Kwin is a good example for the opposite.
There's no clear way to change this setting if you're just a Weston
plugin. Thus, there's just another reason not to go for it, as writing
a compositor yourself proves to be a magnificient chore.

-4) Sucklessness
What should we do then?
My advice would be to take a look at tinyx[2] and tinyxlib[3], which is
relatively small and fitting the purpose well (dwm runs on it).

Let's see what the future will bring us, but it now is all about making
a decision.

Cheers

FRIGN

[1]: <http://www.youtube.com/watch?v=_FjuPn7MXMs>

[Truls Becken]

On 2014-01-14, at 11:42, FRIGN wrote:

> My advice would be to take a look at tinyx[2] and tinyxlib[3], which is
> relatively small and fitting the purpose well (dwm runs on it).
>
> Let's see what the future will bring us, but it now is all about making
> a decision.

I'd like to mention that you don't have to accept xlib to use the X11 protocol.
There is also XCB which is a more direct interface to the protocol, not stripping
it for its asynchronous properties.

-Truls

[Bobby Powers]

Hello,

FRIGN wrote:
> -1) Compositor's demands:
> Not everyone has a full drm-kms-setup. Hell, I don't even use evdev
> on my devices (It's more secure when you strip out the Event Interface
> from the Kernel).

Can you explain your thinking here on security? Is it just that less
compiled code == more secure?

> -2) Code-rot:

> I know, there are libs, but who guarantees they're still around in a
> few years _and_ compatible with the still rather "dynamic" Wayland-API?
> Why not just write a Weston-plugin then? Because Weston sucks (PAM,
> overengineered, too many features for dwm, ...)!

Have you looked much at Weston? PAM integration is limited to 1 file
& 3 functions, and could be trivially excised.

> In the end, you just give up and implement it yourself, forcing you to
> maintain thousands of LOC, risking bugs and wasting your time.

How is this different from the tinyx project you mentioned? Ah,
right, you like tinyx.

yours,
Bobby

[Hadrian Węgrzynowski]

Dnia 2014-01-14, o godz. 11:42:14
FRIGN <d...@frign.de> napisał(a):

> Yes, that's true. However, you need to stress here that Wayland is
> just the protocol implementation for communication between clients and
> server and glue-code between clients and EGL-calls.
> It doesn't pull in the big libs itself, but _implicates_ a compositor
> (server) using EGL to communicate with Mesa 3D.
> On the client side, same applies.
>
> You can't do Wayland without EGL.

EGL as API is quite lean. There could be small implementation not
depending on Mesa 3D.

Is there another problem with EGL?

> Now, where's the problem?
>
> -1) Compositor's demands:
> Not everyone has a full drm-kms-setup. Hell, I don't even use evdev
> on my devices (It's more secure when you strip out the Event Interface
> from the Kernel).
>
> The biggest factor here probably is Mesa 3D. You just don't want this
> overhead if you don't intend to spend most of your time playing around
> with 3D-effects and burning windows.
> Given the direction the mainstream-Linux-desktop is going, Wayland is
> the appropriate answer.
>
> However, having looked into the topic a bit deeper, I basically found
> the Wayland-Compositor-Client model to be very similar to what you get
> implementing a GUI into a video-game[1] combined with several
> util-functions to set _basic_ things up.
>
> Yeah, I know Wayland doesn't require OpenGL(ES), but guess what most
> compositors build upon.

I am just curious:
1. Can Wayland clients use just simple blitting without special kernel
infrastructures?
2. Can Wayland Compositor work without special kernel infrastructures?
3. Are Wayland clients using evdev or is it just for server?
4. Does anybody know how good is pixman library (AFAIK software renderer
used by Weston)?

> -2) Code-rot:
> The Wayland protocol itself may be very lean, but that's not where the
> big overhead comes from. It rather is the fact you need to rewrite
> trivial features like evdev for each new compositor you chose to
> develop.
> I know, there are libs, but who guarantees they're still around in a
> few years _and_ compatible with the still rather "dynamic"
> Wayland-API? Why not just write a Weston-plugin then? Because Weston
> sucks (PAM, overengineered, too many features for dwm, ...)!

I like to think that, we could make up compositor from few buildng
blocks, but I don't know Wayland that much to know is this viable.

> In the end, you just give up and implement it yourself, forcing you to
> maintain thousands of LOC, risking bugs and wasting your time.

$ find swc -iname "*.[ch]" -exec cat '{}' \; | wc -l
8350
$ find tinyxserver -iname "*.[ch]" -exec cat '{}' \; | wc -l
235126

> -3) Window decorations:
> It was noted before, but window decorations are not trivial with
> Wayland.

It is true, but in case of dwm decorations are relativly trivial.

> -4) Sucklessness
> What should we do then?
> My advice would be to take a look at tinyx[2] and tinyxlib[3], which
> is relatively small and fitting the purpose well (dwm runs on it).

That is cool nevertheless.

> Let's see what the future will bring us, but it now is all about
> making a decision.

Even if Suckless Wayland Compositor can be successfully implemented
suckless most probably will not abandon X11 for the foreseeable
future, which I think is good.

Truth is - we can talk, but only written code matters.

With regards,
Hadrian Węgrzynowski.

[FRIGN]

On Tue, 14 Jan 2014 09:43:03 -0500
Bobby Powers <bobby...@gmail.com> wrote:

> Can you explain your thinking here on security? Is it just that less
> compiled code == more secure?

No, it's just my problem with hotplugging input-devices. As my setup
doesn't change (I only have a mouse and keyboard), the respective
x-drivers are sufficient ;).

And of course, it saves some KB from the Kernel.

> Have you looked much at Weston? PAM integration is limited to 1 file
> & 3 functions, and could be trivially excised.

Then I wonder why they don't make it optional as a Compiler-Flag.

> How is this different from the tinyx project you mentioned? Ah,
> right, you like tinyx.

tinyx backports security-patches for X, so it's not a one-man's job.
However, I really have to include Hadrian's response here:

>> $ find swc -iname "*.[ch]" -exec cat '{}' \; | wc -l
>> 8350
>> $ find tinyxserver -iname "*.[ch]" -exec cat '{}' \; | wc -l
>> 235126

, which is definitely a fair point to make.

It may have been to much of a rant in my previous mail. I'm always open
to learn new things about Wayland!

[Michael Forney]

Hi FRIGN,

I tried to respond to most of your points as best I could.

On Tue, 14 Jan 2014 11:42:14 +0100, FRIGN <d...@frign.de> wrote:
> > I believe most of the implementation details are up to the compositor,
> > Wayland is just a protocol.
> > At least in archlinux, the wayland package has only 2 dependencies:
> > libffi and expat
>
> Yes, that's true. However, you need to stress here that Wayland is just
> the protocol implementation for communication between clients and
> server and glue-code between clients and EGL-calls.
> It doesn't pull in the big libs itself, but _implicates_ a compositor
> (server) using EGL to communicate with Mesa 3D.
> On the client side, same applies.
>
> You can't do Wayland without EGL.

Sure, many compositors will use EGL, but that doesn't make it a
requirement. In swc I am using wld to perform both server-side
compositing as well as client-side drawing (as in st). wld includes
hardware accelerated rendering for Intel, and uses the same protocol
extension as Mesa does to pass buffers to the server. This has several
benefits:

- If none of your applications use Mesa or EGL, it is not required.
- If your system uses a GPU that wld does not support, but you have
applications which use EGL/OpenGL, those applications will have
accelerated rendering like normal, and only the final copy to the
scanout buffer will be done in software (which, from my testing,
is quite fast).
- Applications built using wld will remain compatible with other
Wayland compositors which do use EGL.

Additionally, software rendering using pixman will work for nearly all
systems, and is fast enough from my experience.

> Now, where's the problem?
>
> -1) Compositor's demands:
> Not everyone has a full drm-kms-setup. Hell, I don't even use evdev
> on my devices (It's more secure when you strip out the Event Interface
> from the Kernel).

Both of these are just implementation details of the compositor. They
suit my needs fine, so I won't be looking into supporting fbdev or
non-evdev devices. Though I should note, it probably wouldn't be too
difficult at all to support these, but it adds unnecessary bloat at this
point.

> The biggest factor here probably is Mesa 3D. You just don't want this
> overhead if you don't intend to spend most of your time playing around
> with 3D-effects and burning windows.

I agree that Mesa should not be a hard requirement for a functioning
window system. However, it makes sense to utilize it if it is available
on the system.

> Given the direction the mainstream-Linux-desktop is going, Wayland is
> the appropriate answer.
>
> However, having looked into the topic a bit deeper, I basically found
> the Wayland-Compositor-Client model to be very similar to what you get
> implementing a GUI into a video-game[1] combined with several
> util-functions to set _basic_ things up.
>
> Yeah, I know Wayland doesn't require OpenGL(ES), but guess what most
> compositors build upon.

That 3D-maze compositor is a proof-of-concept and should be regarded as
such. If anything, it just illustrates the flexibility granted to the
compositor.

> -2) Code-rot:
> The Wayland protocol itself may be very lean, but that's not where the
> big overhead comes from. It rather is the fact you need to rewrite
> trivial features like evdev for each new compositor you chose to
> develop.

I don't think this is a valid argument. You could say the same thing for
X11: you need to implement these things for every X server you implement
as well.

> I know, there are libs, but who guarantees they're still around in a
> few years _and_ compatible with the still rather "dynamic" Wayland-API?
> Why not just write a Weston-plugin then? Because Weston sucks (PAM,
> overengineered, too many features for dwm, ...)!
> In the end, you just give up and implement it yourself, forcing you to
> maintain thousands of LOC, risking bugs and wasting your time.

I believe that the Wayland API will settle down after a while (in fact,
it has been easy to keep up with and recently it hasn't changed much at
all).

> -3) Window decorations:
> It was noted before, but window decorations are not trivial with
> Wayland.
> There's no problem with forcing the clients to shut up and just take
> the borders the compositor tells them to take (afaik).
> However, Weston is a liberal scumbag allowing the clients to to
> whatever they want. Kwin is a good example for the opposite.
> There's no clear way to change this setting if you're just a Weston
> plugin. Thus, there's just another reason not to go for it, as writing
> a compositor yourself proves to be a magnificient chore.

In swc, I just draw borders for all windows. The window manager can
specify a border width and color for each window, just like in X. My st
and dmenu ports do nothing in terms of borders/window decorations (same
as they currently work in X).

Now, as far as other applications go, Gtk+ currently draws these massive
decorations around everything when running under Wayland. Given that the
Qt/KDE guys want to use server-side decorations, I'm sure that there
will be some setting you can disable to get rid of the borders (maybe
there already is, I haven't looked into it).

I'm in agreement that Weston is not the way to go. I think it would be
quite difficult to add server-side borders to the existing Weston
code-base, and would almost certainly not be accepted upstream.

> -4) Sucklessness
> What should we do then?
> My advice would be to take a look at tinyx[2] and tinyxlib[3], which is
> relatively small and fitting the purpose well (dwm runs on it).
>
> Let's see what the future will bring us, but it now is all about making
> a decision.

I don't think it is so important to make a decision as much as to be
aware of all the possibilities.

Also, while I'm happy that swc is getting attention, it is perhaps
happening just a little too early; don't expect to be able to try it out
right now, I have a lot of changes pending in my working tree which I
hope to get committed over the next few days. Additionally, there are a
couple of final things I need to finish up (mainly VT switching).

--
Michael Forney <mfo...@mforney.org>

[FRIGN]

On Tue, 14 Jan 2014 21:11:20 +0000
Michael Forney <mfo...@mforney.org> wrote:

Hey Michael,

thanks for your response!
I'm glad to get some remarks from a real Wayland-expert (I'm far from
that) and be able to have more insight into the topic.

> Sure, many compositors will use EGL, but that doesn't make it a
> requirement.

> (...)

> Additionally, software rendering using pixman will work for nearly all
> systems, and is fast enough from my experience.

It's a surprise to me, as I really thought Wayland was "built" on EGL.
Thanks for clearing that up!

> I agree that Mesa should not be a hard requirement for a functioning
> window system. However, it makes sense to utilize it if it is available
> on the system.

As I said, Mesa 3d is perfectly fine considering where the
Linux-desktop is heading to. I concur.

> In swc, I just draw borders for all windows. The window manager can
> specify a border width and color for each window, just like in X. My st
> and dmenu ports do nothing in terms of borders/window decorations (same
> as they currently work in X).
> Now, as far as other applications go, Gtk+ currently draws these massive
> decorations around everything when running under Wayland. Given that the
> Qt/KDE guys want to use server-side decorations, I'm sure that there
> will be some setting you can disable to get rid of the borders (maybe
> there already is, I haven't looked into it).
> I'm in agreement that Weston is not the way to go. I think it would be
> quite difficult to add server-side borders to the existing Weston
> code-base, and would almost certainly not be accepted upstream.

If that's just a matter of implementation, this isn't really a problem.

> I don't think it is so important to make a decision as much as to be
> aware of all the possibilities.
> Also, while I'm happy that swc is getting attention, it is perhaps
> happening just a little too early; don't expect to be able to try it out
> right now, I have a lot of changes pending in my working tree which I
> hope to get committed over the next few days. Additionally, there are a
> couple of final things I need to finish up (mainly VT switching).

Do the work you think is necessary for a well-polished product. Wayland won't run away and X is not dead-on-arrival. In the long run, X won't leave us in the next few years, thus, seeing such mature project like yours makes me feel happy inside ;).

Cheers and happy hacking!

FRIGN

--
FRIGN <d...@frign.de>

[Michael Forney]

On Tue, 14 Jan 2014 20:41:40 +0100, Hadrian Węgrzynowski <had...@hawski.com> wrote:
> EGL as API is quite lean. There could be small implementation not
> depending on Mesa 3D.
>
> Is there another problem with EGL?

EGL is fine, but it implies an implementation of OpenGL, which would be
quite complicated to implement.

> I am just curious:
> 1. Can Wayland clients use just simple blitting without special kernel
> infrastructures?

Yes, there is an interface wl_shm in the core protocol which allows
clients to create a shared memory buffer, render to it by whatever means
it wants, and then pass the file descriptor to the server.

> 2. Can Wayland Compositor work without special kernel infrastructures?

The protocol allows it, but at some stage your screen buffer needs to
get scanned out to your monitor, which requires some sort of kernel
interface.

> 3. Are Wayland clients using evdev or is it just for server?

Just the server. Clients receive input events via the wl_keyboard and
wl_pointer interfaces.

> 4. Does anybody know how good is pixman library (AFAIK software renderer
> used by Weston)?

I've found that while it isn't documented that well, it is very useful
and well optimized (from what I can tell). Text rendering was a bit
tough to get working because you have to do glyph arrangement and
rendering yourself (probably using FreeType).

--
Michael Forney <mfo...@mforney.org>

[Dmitrij D. Czarkoff]

Greetings!

Sorry for reviving old thread, but what happened to porting surf to
GTK3?

There was a discussion in January 2014, where Christoph Lohmann said:

> Are there any arguments against switching to GTK3? Otherwise I will
> switch surf to GTK3 using the smootscrolling patch.

surf still depends on GTK2 flavor of WebKit. Any status update?

--
Dmitrij D. Czarkoff

[Christoph Lohmann]

Greetings.

The GTK2 version works for me, so I have no intention to work on the
GTK3 port. GTK3 is adding some hudles in controlling the widgets which
do not allow the old behaviour. It doesn’t looke like the right target
for a future surf interface libraries.


Sincerely,

Christoph Lohmann