Script plugin

[vinipsmaker]

Just creating an issue to keep tracking of any efforts to add a plugin to handle scripting languages (e.g. lua).

Feel free to close it if you think it's inappropriate.

Btw, do you intend to "grow the project" or keep it as a personal project? I mean, there is no site or even a "orbment manifesto" where the purposes are stated (e.g. add features, but only if they are secure). Check https://wiki.archlinux.org/index.php/Arch_Linux#Principles to see what I mean.

I'm planning to migrate to a Wayland compositor and I reduced my list of candidates to orbment and sway. I plan to test both of them in the coming weeks.

[Cloudef]

It's more of personal project. It's centered around plugins especially for reason, that everyone can easily integrate whatever they want and find useful. Lua scripting for example is perfectly appropriate. At some point we might have contrib repository for plugins, while the core is just for basic tiler functionality. E.g. even if I find lua appropriate for plugin, I don't think it belongs to core.

For now I'm aware of only one external plugin and that's @sardemff7's notification-area and that's just hosted on his personal repo https://github.com/sardemff7/wayland-notification-area

[Cloudef]

It's more of personal project. It's centered around plugins especially for reason, that everyone can easily integrate whatever they want and find useful. Lua scripting for example is perfectly appropriate. At some point we might have contrib repository for plugins, while the core is just for basic tiler functionality. E.g. even if I find lua appropriate for plugin, I don't think it belongs to core.

For now I'm aware of only one external plugin and that's @sardemff7's notification-area and that's just hosted on his personal repo https://github.com/sardemff7/wayland-notification-area

[vinipsmaker]

It's more of personal project.

That's okay.

It's centered around plugins especially for reason, that everyone can easily integrate whatever they want and find useful.

I have used Emacs for years and I think the only reason why it is so powerful and adapts to so many scenarios is because it is scriptable. My Emacs isn't customized to extreme levels, but it isn't basic either.

One thing I dislike is Emacs Lisp and my config has been just copy'n'paste from snippets on the web. I don't believe this approach would work for C. The recompile cycle would be annoying too.

All in all, Enlightenment is too buggy and is not Wayland capable. I think it's time to take responsibility for how my desktop environment behaves. Never again I should be disappointed because some cool theme or a plugin I love don't work anymore. I will give away the fancy config GUI convenience and put my hands in dirty script files to make the desktop behave the way it works better for me.

Enlightenment was made for eye-candy and themability, but the theme API breaks so often that the only theme you really can use is the default one. Therefore themability isn't an argument. Also, today I care more about behaviour than eye-candy.

Sorry about the rant, I know it went partially OFF-TOPIC.

How much time do you think an outsider would need to spend to have a simple plugin done? Do you think there is a large API to create bindings for or is it minimal and I wouldn't have much trouble reexporting functions? Which would be the starter point? Is there any doc or should I start with the examples? How about the support, what is your preferred contact form when the subject is orbment? Is orbment an experimental project that you think it served its purpose and you plan to abandon it or are you using it as your main desktop environment and plan to support for more time?

E.g. even if I find lua appropriate for plugin, I don't think it belongs to core.

Sounds reasonable.

[vinipsmaker]

It's more of personal project.

That's okay.

It's centered around plugins especially for reason, that everyone can easily integrate whatever they want and find useful.

I have used Emacs for years and I think the only reason why it is so powerful and adapts to so many scenarios is because it is scriptable. My Emacs isn't customized to extreme levels, but it isn't basic either.

One thing I dislike is Emacs Lisp and my config has been just copy'n'paste from snippets on the web. I don't believe this approach would work for C. The recompile cycle would be annoying too.

All in all, Enlightenment is too buggy and is not Wayland capable. I think it's time to take responsibility for how my desktop environment behaves. Never again I should be disappointed because some cool theme or a plugin I love don't work anymore. I will give away the fancy config GUI convenience and put my hands in dirty script files to make the desktop behave the way it works better for me.

Enlightenment was made for eye-candy and themability, but the theme API breaks so often that the only theme you really can use is the default one. Therefore themability isn't an argument. Also, today I care more about behaviour than eye-candy.

Sorry about the rant, I know it went partially OFF-TOPIC.

How much time do you think an outsider would need to spend to have a simple plugin done? Do you think there is a large API to create bindings for or is it minimal and I wouldn't have much trouble reexporting functions? Which would be the starter point? Is there any doc or should I start with the examples? How about the support, what is your preferred contact form when the subject is orbment? Is orbment an experimental project that you think it served its purpose and you plan to abandon it or are you using it as your main desktop environment and plan to support for more time?

E.g. even if I find lua appropriate for plugin, I don't think it belongs to core.

Sounds reasonable.

[Cloudef]

I have used Emacs for years and I think the only reason why it is so powerful and
adapts to so many scenarios is because it is scriptable. My Emacs isn't customized to
extreme levels, but it isn't basic either.

I completely agree. I use vim (and neovim) though :)

All in all, Enlightenment is too buggy and is not Wayland capable. I think it's time
to take responsibility for how my desktop environment behaves. Never again I should be
disappointed because some cool theme or a plugin I love don't work anymore. I will
give away the fancy config GUI convenience and put my hands in dirty script files to
make the desktop behave the way it works better for me.

Sadly wlc and orbment is buggy as well right now. However I can again agree on your
feeling about your setup breaking constantly, and I think only way to achieve stability
and compatibility is to have very simple foundations.
I don't think wayland design as now complements this (more on this below).

There is experimental vfs plugin in another branch of orbment, that gives plugins
ability to export their features as filesystem. Thus suddenly language is irrelevant
and you can for example take pixels of screen by reading file. Sadly linux doesn't have
good foundations for this kind of interface design. So I wrote some library to
implement 9p server inside orbment, I may still consider testing FUSE out as well for
this purpose. Personally I think filesystems are the better approach for modulari/ty,
and really anything that includes external input / output, since language doesn't matter
anymore and it forces you to design your interfaces sanely. However plugins still have
their place for extending and changing logic inside orbment, so I chose to opt for both.
I think file systems would be the more important interface for most users however.

How much time do you think an outsider would need to spend to have a simple plugin
done?

Depends on scope of plugin, but for example dpms plugin should give quite good idea on
how simple plugins may look.

Do you think there is a large API to create bindings for or is it minimal and I
wouldn't have much trouble reexporting functions?

For exposing lua API, all you really need is to way to bind the functions and
structures defined in plugin.h, then you can access everything C plugin could.
For orbment plugins also define standard syntax for defining function signatures, so
you may be to generate lua bindings or something from this. Right now such signatures
are managed manually, but they are there mainly to prevent bigger ABI breaks between
plugins, or to support older version of function if some plugin decides to use it. It's
not bullet proof solution of course (as if anything native were), but I thought it was
good idea to have especially since plugins can interact with each other, and for
potential future code generation / static analysis purposes.

Is there any doc or should I start with the examples?

plugin.h is quite well documented, the core plugins are quite nice and small. I had
plan to use erlang style (basically man pages) documentation for plugins. But this is
just "ecosystem" detail, all orbment cares for is those few exported functions and some
plugin api calls.

How about the support, what is your preferred contact form when the subject is orbment?

IRC is preferred, I'm mainly thinking of going away from github for my future projects.

Is orbment an experimental project that you think it served its purpose and you plan
to abandon it or are you using it as your main desktop environment and plan to support
for more time?

Orbment in way is not tied to wayland. I think it has potential as modular desktop
window manager / shell. It's experimental of course, but I have quite warm feelings for
it. However the base it uses wlc (or wayland), is something I don't like as much and
wish there were simpler alternative. As for now I can honestly say it's on hiatus and
I'm working on other things, work and game project. But if I get the ich to create
"better desktop enviroinment" again, I'll get back or at least use orbment as
inspiration.

On Wayland, and why I don't think it suits orbment well (rant time).
First of all, wayland is designed for toolkits. Thus the standards defined in the
protocol as of now are centered around needs of toolkits. Most of these details are
totally irrelevant to my daily usecases, and I only care about having buffer from
client and showing it on screen.. That's it. Wayland ecosystem as of now doesn't really
achieve this, it achieves much more which just makes everything more complicated and
depressing to me.

For now to have functional compositor (from user point of view), you need to do the
following:

• Support standard protocol for surfaces
  • This includes details like handling surface rotation, scale, input areas and other
    crap on compositor side.
  • Each client may have many surfaces, thus clients are not self-contained (like for
    example games), complicating everything compositor side. All this to just show
    another window or tooltip outside of their viewport.
• Input
  • Different kind of input devices must be supported by compositor and have own
    protocol. Even if linux supported some device, it doesn't matter if the wayland
    ecosystem does not. Input data can't be used directly, which may cripple the features
    you may use.
  • Input must be transformed for surface, which may be rotated, scaled, etc..
• Support standard surface roles (aka window types)
  • Popups
  • Windows
    • These windows may define states for whatever reason that should be completely
      irrelevant. There is no reason for client to know whether it's minimized or
      anything really. Just let the compositor decide where and how the window is
      drawn.
• Configuration
  • This is probably my biggest gripe. Since interfaces in wayland ecosystem are all
    just some C libraries with API's, it means every compositor proxies these api
    functions as some form of external configuration (usually file).
  • This sucks as it means every compositor has their own buggy configuration.
  • This sucks as the compositor limits how you configure your hardware.
  • There is absolutely zero reason for doing it this way.
  • Hardware configuration ideally would be just filesystem where you can write your
    changes, like for example enabling tap to click on touchpad. It should not need
    to be supported by compositor, nor compositor really should proxy all this crap
    that is actually singlenton in real world anyways, but we do it because of
    "security".
• Lifecycles
  • There are many resources clients may create to compositor side.
    These resources are opaque pointers that may appear / disappear anytime.
    This makes it quite hard to make sure everything is still in valid state, and
    that the resources itself doesn't contain garbage. Every new protocol adds new
    moving part (resource).
    WAYLAND_DEBUG=1 can give you good idea what happens under the hood.
• Legacy compatibility
  • Compositor needs to have X window manager inside.
  • Compositor needs to have X clipboard manager inside.
  • Xwayland is actually single client and thus now every X client is bit special..
    Not to mention that X concepts are totally otherwordly from wayland concepts
    regarding window type (roles in wayland) and so on..
• Graphical mode && Rendering
  • This is obvious, and it's quite in depth. So far I think linux graphics stack and
    apis are quite complicated and underdocumented. There are lots of annoyances
    (especially when doing hw acclerated rendering) here but it's something you have
    to do anyway. Not big deal, and can be countered with knowledge and good design.
    I'm willing to acknowledge own incompetence on this area as well, and things like
    EGL / OpenGL by their design making everyone's life harder. But you can already
    imagine some scenarios like having 2 different GPU's where both are connected to
    own monitor, being actually quite damn complicated on software side. 2 monitors
    for example when using EGL / OpenGL as acceleration for compositor implies, that
    you have context for each monitor, which means you can't simply share resources
    between these contextes, which in other terms means, things like rendering window
    at the cut off point of monitors needs copy of the resources on multiple contextes
    and multiple renders on multiple contexts.

This is all quite too much for something that doesn't care about legacy compatibilty at
all or toolkit craziness, (Why can't client just draw inside themself). Or input,
why can't client just read directly and use what OS gives them. (I don't care about
security if it cripples usefulness, though plan9 actually has even solution to this
that doesn't even depend on display manager, and that was namespaces and masking of
file systems), I could go on.. But basically all I do daily is have bunch of terminals
open and one crappy web browser. Sometimes I watch videos on my mpv and use blender or mypaint.
None of these need any of the craziness wayland ecosystem implements.

I originally thought I could hide all this crap under wlc. However I don't think it
succeeded very well. I think the only way to have stable and nice implementation of
this is to have great deal of discipline and rely on code generation practices, like
modelling the compositor logic and protocol interactions as finite state machine.
Great deal of problems also come from lower level, like fd passing, graphical tty woes,
tty switching, DRM and so on.

I would really recommend using libweston nowadays for anything wayland centric, as it's
developed by the people at #wayland, and even though it's huge and contains everything
at least it must work since it's considered as "reference compositor".

As for alternatives to wayland, I've been thinking of arcan https://arcan-fe.com/.
Not sure if it yields the level of simplicity I'm looking for, but without spending
more time on the details, I'm not even sure if it's possible or if it's just my naivety.

But for certainly I can say that wayland experience to me hasn't been very pleasant.

[Cloudef]

I have used Emacs for years and I think the only reason why it is so powerful and
adapts to so many scenarios is because it is scriptable. My Emacs isn't customized to
extreme levels, but it isn't basic either.

I completely agree. I use vim (and neovim) though :)

All in all, Enlightenment is too buggy and is not Wayland capable. I think it's time
to take responsibility for how my desktop environment behaves. Never again I should be
disappointed because some cool theme or a plugin I love don't work anymore. I will
give away the fancy config GUI convenience and put my hands in dirty script files to
make the desktop behave the way it works better for me.

Sadly wlc and orbment is buggy as well right now. However I can again agree on your
feeling about your setup breaking constantly, and I think only way to achieve stability
and compatibility is to have very simple foundations.
I don't think wayland design as now complements this (more on this below).

There is experimental vfs plugin in another branch of orbment, that gives plugins
ability to export their features as filesystem. Thus suddenly language is irrelevant
and you can for example take pixels of screen by reading file. Sadly linux doesn't have
good foundations for this kind of interface design. So I wrote some library to
implement 9p server inside orbment, I may still consider testing FUSE out as well for
this purpose. Personally I think filesystems are the better approach for modulari/ty,
and really anything that includes external input / output, since language doesn't matter
anymore and it forces you to design your interfaces sanely. However plugins still have
their place for extending and changing logic inside orbment, so I chose to opt for both.
I think file systems would be the more important interface for most users however.

How much time do you think an outsider would need to spend to have a simple plugin
done?

Depends on scope of plugin, but for example dpms plugin should give quite good idea on
how simple plugins may look.

Do you think there is a large API to create bindings for or is it minimal and I
wouldn't have much trouble reexporting functions?

For exposing lua API, all you really need is to way to bind the functions and
structures defined in plugin.h, then you can access everything C plugin could.
For orbment plugins also define standard syntax for defining function signatures, so
you may be to generate lua bindings or something from this. Right now such signatures
are managed manually, but they are there mainly to prevent bigger ABI breaks between
plugins, or to support older version of function if some plugin decides to use it. It's
not bullet proof solution of course (as if anything native were), but I thought it was
good idea to have especially since plugins can interact with each other, and for
potential future code generation / static analysis purposes.

Is there any doc or should I start with the examples?

plugin.h is quite well documented, the core plugins are quite nice and small. I had
plan to use erlang style (basically man pages) documentation for plugins. But this is
just "ecosystem" detail, all orbment cares for is those few exported functions and some
plugin api calls.

How about the support, what is your preferred contact form when the subject is orbment?

IRC is preferred, I'm mainly thinking of going away from github for my future projects.

Is orbment an experimental project that you think it served its purpose and you plan
to abandon it or are you using it as your main desktop environment and plan to support
for more time?

Orbment in way is not tied to wayland. I think it has potential as modular desktop
window manager / shell. It's experimental of course, but I have quite warm feelings for
it. However the base it uses wlc (or wayland), is something I don't like as much and
wish there were simpler alternative. As for now I can honestly say it's on hiatus and
I'm working on other things, work and game project. But if I get the ich to create
"better desktop enviroinment" again, I'll get back or at least use orbment as
inspiration.

On Wayland, and why I don't think it suits orbment well (rant time).
First of all, wayland is designed for toolkits. Thus the standards defined in the
protocol as of now are centered around needs of toolkits. Most of these details are
totally irrelevant to my daily usecases, and I only care about having buffer from
client and showing it on screen.. That's it. Wayland ecosystem as of now doesn't really
achieve this, it achieves much more which just makes everything more complicated and
depressing to me.

For now to have functional compositor (from user point of view), you need to do the
following:

• Support standard protocol for surfaces
  • This includes details like handling surface rotation, scale, input areas and other
    crap on compositor side.
  • Each client may have many surfaces, thus clients are not self-contained (like for
    example games), complicating everything compositor side. All this to just show
    another window or tooltip outside of their viewport.
• Input
  • Different kind of input devices must be supported by compositor and have own
    protocol. Even if linux supported some device, it doesn't matter if the wayland
    ecosystem does not. Input data can't be used directly, which may cripple the features
    you may use.
  • Input must be transformed for surface, which may be rotated, scaled, etc..
• Support standard surface roles (aka window types)
  • Popups
  • Windows
    • These windows may define states for whatever reason that should be completely
      irrelevant. There is no reason for client to know whether it's minimized or
      anything really. Just let the compositor decide where and how the window is
      drawn.
• Configuration
  • This is probably my biggest gripe. Since interfaces in wayland ecosystem are all
    just some C libraries with API's, it means every compositor proxies these api
    functions as some form of external configuration (usually file).
  • This sucks as it means every compositor has their own buggy configuration.
  • This sucks as the compositor limits how you configure your hardware.
  • There is absolutely zero reason for doing it this way.
  • Hardware configuration ideally would be just filesystem where you can write your
    changes, like for example enabling tap to click on touchpad. It should not need
    to be supported by compositor, nor compositor really should proxy all this crap
    that is actually singlenton in real world anyways, but we do it because of
    "security".
• Lifecycles
  • There are many resources clients may create to compositor side.
    These resources are opaque pointers that may appear / disappear anytime.
    This makes it quite hard to make sure everything is still in valid state, and
    that the resources itself doesn't contain garbage. Every new protocol adds new
    moving part (resource).
    WAYLAND_DEBUG=1 can give you good idea what happens under the hood.
• Legacy compatibility
  • Compositor needs to have X window manager inside.
  • Compositor needs to have X clipboard manager inside.
  • Xwayland is actually single client and thus now every X client is bit special..
    Not to mention that X concepts are totally otherwordly from wayland concepts
    regarding window type (roles in wayland) and so on..
• Graphical mode && Rendering
  • This is obvious, and it's quite in depth. So far I think linux graphics stack and
    apis are quite complicated and underdocumented. There are lots of annoyances
    (especially when doing hw acclerated rendering) here but it's something you have
    to do anyway. Not big deal, and can be countered with knowledge and good design.
    I'm willing to acknowledge own incompetence on this area as well, and things like
    EGL / OpenGL by their design making everyone's life harder. But you can already
    imagine some scenarios like having 2 different GPU's where both are connected to
    own monitor, being actually quite damn complicated on software side. 2 monitors
    for example when using EGL / OpenGL as acceleration for compositor implies, that
    you have context for each monitor, which means you can't simply share resources
    between these contextes, which in other terms means, things like rendering window
    at the cut off point of monitors needs copy of the resources on multiple contextes
    and multiple renders on multiple contexts.

This is all quite too much for something that doesn't care about legacy compatibilty at
all or toolkit craziness, (Why can't client just draw inside themself). Or input,
why can't client just read directly and use what OS gives them. (I don't care about
security if it cripples usefulness, though plan9 actually has even solution to this
that doesn't even depend on display manager, and that was namespaces and masking of
file systems), I could go on.. But basically all I do daily is have bunch of terminals
open and one crappy web browser. Sometimes I watch videos on my mpv and use blender or mypaint.
None of these need any of the craziness wayland ecosystem implements.

I originally thought I could hide all this crap under wlc. However I don't think it
succeeded very well. I think the only way to have stable and nice implementation of
this is to have great deal of discipline and rely on code generation practices, like
modelling the compositor logic and protocol interactions as finite state machine.
Great deal of problems also come from lower level, like fd passing, graphical tty woes,
tty switching, DRM and so on.

I would really recommend using libweston nowadays for anything wayland centric, as it's
developed by the people at #wayland, and even though it's huge and contains everything
at least it must work since it's considered as "reference compositor".

As for alternatives to wayland, I've been thinking of arcan https://arcan-fe.com/.
Not sure if it yields the level of simplicity I'm looking for, but without spending
more time on the details, I'm not even sure if it's possible or if it's just my naivety.

But for certainly I can say that wayland experience to me hasn't been very pleasant.

[vinipsmaker]

wow

Thanks for the big response/time.

Very nice to read.

[vinipsmaker]

wow

Thanks for the big response/time.

Very nice to read.