EWW Configuration rework

[elkowar]

UPDATE

At this point, it seems like a clear winner has crystallized: the s-expression syntax!
I will most likely start implementing the new syntax soon! It will still take a while, but it's gonna happen.

Main post

XML Sucks. We all agree on that. While it works*, that asterisk is a very large one. Strings constantly cause issues, specifically in script-vars there are a ton of issues with escaping stuff properly. workarounds like < for comparisons are,.... disgusting.
Thus: An alternative needs to be found.
I currently tend towards making the configuration language a form of s-expressions (the stuff you see in lisps). Sexpressions have a couple benefits:

• S-expressions are a well-known structure that can represent data in a clean yet human readable way.
• Editor support for general sexpression syntax exists everywhere, and with tools like parinfer being available, editing sexpression trees is a blast.
  -S-expressions are a very simple syntax, easy to parse and deal with, both from the code side as well as the user side - generating s-expressions from a script for use in <literal> would be extremely easy.

They also have a big negative though, and that is that they look somewhat weird to people not yet exposed to them, and may be a turnoff for a couple (less serious) users. Depending on how the reactions to this are, that may be a dealbreaker.

I am thus also open for other ideas and proposals. If you have any concrete ideas or thoughts, please do comment here. This discussion thread is going to be the place to collect ideas and thoughts before I make a decision.

Please like the syntax proposals you enjoy, and do comment on what you like and dislike.

For a syntax proposal, please write equivalent of the following XML in your proposed syntax:

<eww>
  <definitions>
    <def name="something">
      <box class="{{arg}}" halign="start">
        click this button:
        <button onclick="notify-send 'test' 'message'">
          {{some_script}}
        </button>
      </box>
    </def>
  </definitions>
  <variables>
    <var name="some_var">
      foo
    </var>
    <script-var name="some_script" interval="1s">
      date | sed 's/:/X/g' | rev
    </script-var>
  </variables>
  <windows>
    <window name="foo">
      <geometry anchor="center" width="100px" height="10%"/>
      <widget>
        <something arg="{{some_var}}"/>
      </widget>
    </window>
  </windows>
</eww>

Also:
Given that I hate neither myself nor my users enough for that, I'm definitely_ not gonna do any indentation-sensitive language.

Also also:
Note that I may at some point write up a language-server for eww, or some other simpler validation scheme. This may be relevant for the syntax, as the option to optionally specify types may be provided in the future.

[elkowar]

Proposed S-expression syntax

NOTE that the {} around the properties here may also be removed, depending on how people like it.

(def-widget something [arg]
  (box {:class arg 
        :halign "start"}
    (text "Click this button:")
    (button {:onclick "notify-send 'test' 'message'"}
      (text "some_script"))))

(def-var some_var "foo")
(def-script-var some_script {:interval "1s"}
  "date | sed 's/:/X/g' | rev")

(def-window foo
  {:anchor "center"
   :width "100px"
   :height "10%"}
  (something {:arg some_var}))

[mfdorst]

Is YAML a possibilty?

[elkowar]

Is YAML a possibilty?

No, for two reasons:

1. Its absolute pain
2. Write up the given config example, and you'll notice yourself that yaml cannot cleanly encode a hierarchical relationship at all.

[undefinedDarkness]

Yaml is like JSON but without {} and ""

[iSparsh]

YAML is indentation hell. If you want to have a stroke just work with the alacritty.yml config. Please no YAML.

[ariealerr]

this one's my favorite

[elkowar]

Another, kotlin-inspired option

widget something(arg) {
  box(class = arg, halign = "start") {
    text { "Click this button:" }
    button(onclick = "notify-send 'test' 'message'") {
      text { some_script }
    }
  }
}

var some_var { "foo" }
scriptvar some_script(interval="1s") {
  "date | sed 's/:/X/g' | rev"
}

window foo(
  anchor="center", 
  width="100px", 
  height="10%",
) {
  something(arg = some_var)
}

This isnt all that bad in the widget definition, but as soon as it gets to the other parts, it get's weird. Eww is not a programming language, and mapping the syntax of one to eww doesn't really work. I strongly prefer sexpressions over this for now, although I can see how others may prefer something like this.

[mTvare6]

Definitely make sense, Ubersicth does the same but with js, so maybe have a "api" using which we can run shell commands, and be able to export values and css as objects which eww parses

[snakedye]

I find this more readable and accessible, probably because the syntax is more familiar.

[elkowar]

Definitely make sense, Ubersicth does the same but with js, so maybe have a "api" using which we can run shell commands, and be able to export values and css as objects which eww parses

GTK doesn't really allow to just reset stuff easily, so the API would be rather confusing. Additionally, if I made eww into a programming API rather than a declarative config structure, the barrier of entry would be much higher, simple stuff would be much more complex to implement, and that would imply a full rewrite of eww, with a completely different design goal. If you're up for it: make a fork. Otherwise,... Eww is gonna stay declarative for now.

[legendofmiracles]

services.eww = {
  config = {
    definitions = {
      something = [
        ("box" { class = "{{arg}}"; halign = "start"; } [
          "click this button:" (button { onclick = "notify-send 'test' 'message'"; } [
            "{{some_script}}"
          ])
        ])
      ];
    };
    variables = {
      variables = {
        some_var = "foo";
      };
      script_vars =  {
        some_script = {
          delay = "1s";
          command = "date | sed 's/:/X/g' | rev";
        };
      };
    };
    windows = {
      foo = {
        geometry = {
          anchor = center; # dunno if this would have to be in ""
          width = "100px";
          height = "10%";
        };
        widget = [
          ("something" { arg = "{{some_var}}"; } [])
        ];
      }
    }
  };
};

Quick nix solution I hacked together, based on what was discussed in #nixos on the nix discord server yesterday. And they even got a semi working transpiler to work, so I could have transpiled this to xml right now.

[elkowar]

Interesting! Definitely not gonna use nix syntax as the config language, but if you want to maintain a home-manager module wuth that kind of syntax, i'm all for it!

[legendofmiracles]

Issue with that is, is that eww won't get into nixpkgs

Packaging nightly rust is pain

[auscyber]

but you could have an extra module. that people can integrate into their config

[iSparsh]

I prefer the first syntax more that I look at it. This is my take on its formatting and weird mixture of different styling and conventions. I have also made some other changes. Not sure if anyone'll like it though. I don't know if this is possible too.

(include-file "path_to_file")

(def-widget name [args]
    (box [class="some-class", halign="start"]
        (text "Click Here")
        (button [onclick="notify-send 'test' 'message'"]
            (text "some_scipt")
        )
    )
)

(def-var some_var "foo")

(def-script-var some_script [interval="1s"]
    "date | sed 's/:/X/g' | rev"
)

(def-window somewindow [anchor="center", width="100px", height="10%"]
    (something [arg=some_variable])
)

Notes / What's Different / Other things

• Curly Braces
  Instead of using {} and :, we make use of [] like a list of args separated by , instead of using : and {}

• Styling
  Single line "declarations" like simple varibles can be done on one line.
  Indentation of inner blocks. Obviously the enforcing of this indentation depends on it's implementation.

[vladimirlucifer]

This is also a very clean S-Expression Syntax. Looks beautiful.

[mixolydianmel]

JSON shares a lot of the upsides S-expressions possess, but without looking too weird. Directly converting the XML to JSON is also supported, but looks kind of messy. There's also the fact that a lot of people don't like to use JSON because of its association with JavaScript or simply because they don't like the way it looks. As you said for S-expressions,

• JSON is a well-known format that can represent data in a human-readable way
• Editor support for JSON is well-developed and there is a large ecosystem of tools that work with JSON

{
   "eww": {
      "definitions": {
         "def": {
            "box": {
               "button": {
                  "onclick": "notify-send 'test' 'message'",
                  "text": "{{some_script}}"
               },
               "class": "{{arg}}",
               "halign": "start",
               "text": "click this button:"
            },
            "name": "something"
         }
      },
      "variables": {
         "var": {
            "name": "some_var",
            "text": "foo"
         },
         "script-var": {
            "name": "some_script",
            "interval": "1s",
            "text": "date | sed 's/:/X/g' | rev"
         }
      },
      "windows": {
         "window": {
            "geometry": {
               "anchor": "center",
               "width": "100px",
               "height": "10%"
            },
            "widget": {
               "something": {
                  "arg": "{{some_var}}"
               }
            },
            "name": "foo"
         }
      }
   }
}

[undefinedDarkness]

Please, for the sake of all that is good in this world, not this

[legendofmiracles]

And way too many ""

[VuiMuich]

On second thought I agree JSON might va a bad idea. I'll withdraw my "👍"

[anders-hig-jackson]

Json DO look wierd.

[victorbnl]

Or the YAML version :

eww:
  definitions:
    def:
      box:
        button:
          onclick: notify-send 'test' 'message'
          text: "{{some_script}}"
        class: "{{arg}}"
        halign: start
        text: 'click this button:'
      name: something
  variables:
    var:
      name: some_var
      text: foo
    script-var:
      name: some_script
      interval: 1s
      text: date | sed 's/:/X/g' | rev
  windows:
    window:
      geometry:
        anchor: center
        width: 100px
        height: 10%
      widget:
        something:
          arg: "{{some_var}}"
      name: foo

But children would still be a pain

[nixypanda]

I have very little experience with UI-related stuff, HTML, CSS, js still give me nightmares. Though when fiddling around with frontend I came across elm. Which felt way better to do UI stuff compared to HTML/CSS/js. I am not sure but something like that could be super helpful here too from a user's perspective. From a development standpoint, I really don't know (if it is even possible).
Though the styling and layout part still sucked with it, that is where elm-UI comes in and it was a super intuitive way to deal with all this. In this particular example here is what it could potentially look like if something similar to elm was used.

import EWW.ScriptUtils exposing executeScript, executeCronScript
import EWW.UI.Components (row, div)
import EWW.UI.Attributes (centerX, centerY, width, height)

soemthing script =
  div []
    [ text ("click this button")
    , button [onClick (NotifySend "text message")] (executeScript script)
    ]

some_var =
  "foo"

script_var =
  executeCronScript (seconds 1) "date | sed 's/:/X/g' | rev"

main = window []
  [ row [ centerX, centerY, width (px 100), height (pct 10) ]
      [ div [ alignRight ] [ something some_var ] ]
  ]

• More about elm
• More about elm-ui
• Building a design toolkit - Talk: Covers the thought process behind elm-ui
• Here is an example of what stuff actully looks like with elm and elm-ui

[elkowar]

I definitely enjoy Elm as a language, but using it (or implementing something like it) in eww is sadly rather infeasible. It's a fully fledged programming language, which eww explicitly does not want to be - it could only ever be a bad one, whereas it has the opportunity to be a nice DSL.

Elm-like syntax, while I personally really enjoy it, is generally even more "weird" looking to most people than S-expressions, is quite a lot more complex to parse and make consistent. Using a syntax like this would, imo, not provide much value over s-expressions, and would thus not be worth the cost.

As you really seem to enjoy Elm (which I can relate to, I've used it at work - while quite limited in expressivity compared to HS/Purescript, I loved my time with Elm), if you want to play around with using actual elm for desktop widgets, you might want to take a look at https://github.com/anko/hudkit.

[nixypanda]

Elm-like syntax, while I personally really enjoy it, is generally even more "weird" looking to most people than S-expressions,

I have to agree with what you are saying here. It's such a shame that this syntax (*ML-like) is not more popular. and it would be significantly harder to parse compared to the s-expressions.

(which I can relate to, I've used it at work - while quite limited in expressivity compared to HS/Purescript, I loved my time with Elm). if you want to play around with using actual elm for desktop widgets, you might want to take a look at https://github.com/anko/hudkit.

Absolutely, I only delve in to Haskell from time to time only. Thanks for the link too. Will check this out.

P.S. Great work with EWW!

[undefinedDarkness]

Please not this, this is very off - putting and makes me think of haskell which I very much dislike

[Axarva]

Was it just me that saw haskell at first glance

[elkowar]

@Axarva Elm is kinda similar to haskell, and in syntax it definitely is very similar.

[jack-michaud]

XML Sucks. We all agree on that.

I'm not surprised that alternatives to XML are being considered, but I'd like to start a discussion challenging this.

When I first saw this project, I was excited about it because I have never made a GTK applet, but I have many years of HTML under my belt with experience in many different templating syntaxes (Jinja, Handlebars, React, etc.). Figuring out CSS styling for GTK apps was a simple peruse through EWW's excellent docs away and I was cooking on EWW very quickly.

For me, XML represents heirarchy of apps excellently and I find it very friendly for this context.

While it works*, that asterisk is a very large one. Strings constantly cause issues, specifically in script-vars there are a ton of issues with escaping stuff properly. workarounds like < for comparisons are,.... disgusting.

Obviously something needs to change, but it's not like templates with string escaping isn't a solved problem. https://www.arewewebyet.org/topics/templating/

I would vie for upgrading the XML parser to be more fully featured by adopting a fully featured templating language. A fully featured templating language implementation will have solved the string interpolation issue and have componentization and variables built in. I think this is a flexible and backwards compatible way forward.

Below is a proposal of a structure that we could have if we adopted a templating language like Jinja2 using Tera:

# ./eww.html

# Same high level structure as before, but with the power of templating.

# Setting a variable.
# Supports rust expressions, custom functions, etc. 
{% set some_var = "foo" %}

# Setting a script variable using a custom makeScript function
# https://tera.netlify.app/docs/#functions
# Renders to "whatever you need" under the hood.
{% set_global some_script = makeScript(script="date | sed 's/:/X/g' | rev", interval="1s") %}

# Anything can be moved into separate files and imported. 
{% import "components.html" as components %}

<eww>
  <windows>
    <window name="foo">
      <geometry anchor="center" width="100px" height="10%"/>
      <widget>
        {{ components::something(arg=some_var) }}
      </widget>
    </window>
  </windows>
</eww>

# ./components.html

# Macro definition for variable component
# https://tera.netlify.app/docs/#macros
{% macro something(arg, type="text") %}
<box class="{{ arg }}" halign="start">
  click this button:
  <button onclick="notify-send 'test' 'message'">
    {{ some_script }}
  </button>
</box>
{% endmacro something %}

For more complicated examples, extending existing blocks and components is trivial. You can support custom Rust functions and macros within the template. This is an exciting step forward rather than reinventing the wheel in another configuration language.

That's my pitch for a more fully featured XML, but please let me know if I'm in the minority. I'd love to hear more rationale from @elkowar and the community about their troubles with XML so we can have more established and community driven reasoning for migrating away.

Edit: Indentation fix, use set_global instead of set for some_script

[elkowar]

My reason for wanting to migrate away (in addition to what's mentioned above already) is - rather selfishly - that I want to be in control of the syntax and configuration. I've been planning to at some point maybe create a language-server, for example.
Designing such things around an existing implementation/syntax is rather difficult, as I'm inherently restricted in what I'm able to achieve. Of course XML syntax (especially with templates like that) is rather flexible - but also one of the ugliest things on earth.

So, as I'm redesigning and reimplementing anyways, this is a great opportunity to design a syntax that is designed around the exact usecase, rather than taking an already ugly thing and tacking foreign macro syntax on top of it.

I see the argument of XML feeling "comfortable" for web-developers - of course understandable.
But: I'm very sure that adjusting to a slightly different syntax is not all that much effort for anyone. As long as the decided eww-syntax is simple, consistent and intuitive, adjusting shouldn't be an issue.
Either way, more than raw syntax is not really transferable from HTML anyways, as tags have different names, properties are different and layouting works very differently. SCSS will most likely stay, either way.

Thus, I don't think it's a worthwhile tradeoff to live with a painful development experience, sub-par support applicationside and unnecessary uglyness in return for staying in the comfort-zone of a subset of developers.

Another point that I noticed is that many non-webdevs seem to specifically be scared of XML syntax, stating that "they don't know any XML", and fearing that they would thus have a hard time starting out with eww. the fact that XML is already established as a complex layouting language seems to make it less approachable for (at least some) people that haven't done any webdevelopment.

[manderio]

I see your proposal and i highly disagree. For one reason, sane structure.

Even with your proposal, there is no good way of structuring it where you can keep everything in one place.

Take this for example: you have a set of widgets and a bar

Great! But with XML, keeping that structure together becomes really tedious.
Here's an example from my config:

<!--  bar configuration  -->
<!--  the bar itself  -->
<def name="bar0">
<box orientation="h" hexpand="false" space-evenly="true">
<leftside/>
<divider/>
<centerside/>
<divider/>
<rightside/>
</box>
</def>
<!--  second monitor bar  -->
<def name="bar1" class="bar">
<box orientation="h" hexpand="false" space-evenly="true">
<centerside/>
</box>
</def>
<def name="test">
<box orientation="h" hexpand="false">
<test/>
</box>
</def>
<!--  defining sections of eww bar  -->
<def name="leftside" orientation="h" space-evenly="false" halign="start">
<box class="workspaces">
<workspaces/>
</box>
</def>
<def name="centerside" orientation="h" space-evenly="true" halign="center">
<box class="time">
<time/>
</box>
</def>
<def name="rightside" orientation="h" space-evenly="false" halign="start">
<box class="sysinfo">
<sysinfo/>
</box>
</def>

See how I have all of the bar stuff in one place? If I want to add widgets, i can't add the bar variables in the same group since i can't have more than one definitions block. This is a pain for keeping your file structured. And that's not even mentioning the pain that is having to open and close your boxes using several lines.

My current config is at ~200 lines. The only thing I've fully configured is my bar, have barely gotten started on more of the widgets and the config is already hard to keep clean as it is. A language that allows for more structured configuration is way better in my opinion.

Like the ability to have a structure like this:

• bar

  • bar boxes
  • bar variables
  • bar positioning

• widget

  • widget boxes
  • widget variables
  • widget positioning

Is something eww desperately needs in my opinion. Of course making things compatible is important too, however, keeping a language that could be better isn't really feasible in my opinion. If you would like to keep the old option, perhaps a "classic" compile option could be an alternative? Allowing you to use the old code and config structure if you so choose. Of course this wouldn't be maintained unless someone decides to do so. But I would say this is a better option than keeping a structure that is very much a mess configuration wise.

Edit: formatting

Also. Should be noted that I'm not saying that my configuration isn't perfect, it still needs to maintain a certain structure to work with the XML formatting.

[jack-michaud]

Thanks for your responses, @elkowar and @manderio - Your specific reasons sit better with me compared to the initial post's reasoning.
Let me try to distill down some reasons for switching away from XML for posterity:

• Its developer experience is lacking
• It is expressive but cumbersome for extensibility
• Its syntax will scare some people away
• It encourages the people who know HTML to try to write HTML-like widgets when that isn't ergonomic

The rest of the reasons for switching to a new configuration syntax is just icing on the cake. I'm all for it. Thank you for humoring my suggestion!

[elkowar]

Thanks for understanding! It's of course still a valid suggestion - just one that I personally would only take if there was a very clear one-sided community reaction to this, lol

[undefinedDarkness]

This is some lua-ey syntax ig since ive been working with that recently
I hope its different enough from the nix proposal heh

eww {
  definitions = {
    widget {
      name = "something",
      -- additional widget attrs
      box {
        class="{{arg}}",
        halign="start",
        inner = "click this button:", -- this feels ugly to me but whatever
        button {
          onclick="notify-send 'test' 'message'",
          inner = "{{some_script}}",
        }
      }
    }
  },
  variables = {
    some_var = "foo",
    script-var  {
      name="some_script",
      interval="1s",
      command = "date | sed 's/:/X/g' | rev"
    }
  },
  widows = {
    window {
      name="foo",
      geometry = { 
        anchor="center",
        width="100px",
        height="10%"
      },
      widget = { -- this can be done in a neater way ofc
        widget = 'something',
        arg="{{some_var}}"
      }
    }
  }
}

[elkowar]

Well currently its strings. Thing is i godda know which variables are used where such that i can then know which UI things need to be updated when the state changes

[Kqzz]

Honestly, I really like this option. I don't know much about ui or syntax things, but this looked quite readable to me and something I'd work with.

[undefinedDarkness]

Can't you have an api for timers and spawning like in awesome wm and make users do that logic 🤔

[elkowar]

Can't you have an api for timers and spawning like in awesome wm and make users do that logic 🤔

I mean, i could completely scratch the reactive state architecture and make eww a lua library - but at that point, just use GTK directly, lol

[undefinedDarkness]

:kek: yeah makes sense

[elkowar]

Another option that I just remembered: https://github.com/judnich/TupleMarkup
(Not necessarily this exactly, but something along those lines. I'll write up the full proposal tomorrow)

[undefinedDarkness]

This looks quite nice

[manderio]

I like this, a bit square, but I really like it

[VuiMuich]

This reminds me that I thought of suggesting toml, but was hesitant as I am not sure if I could come up with a proper example.

[GoldsteinE]

TOML doesn't really fit here. It's spectaculary bad at encoding nested structures, and eww config is basically nothing but nested structures.

[VuiMuich]

Thanks for saving me the struggle to attempt this 😬

[drager]

Have you considered using html and css together with something like https://github.com/bodil/typed-html ? 😊

[elkowar]

How would that solve anything? that only affects my code, in no way the configuration - and it doesn't improve anything 🤔

[drager]

I don't have so much knowledge of this project, so I might be totally off :) I just thought configuration/letting users write widgets could be done using html and css, and at the same time leverage the power of rust. But as I said, I might be totally off.

[elzii]

My 2c:

I don't mind XML at all. Dont know if there's discussion of this, but I would love to first see things like:

• looping logic capabilities at template level ala Jinja / Handlebars / etc.
• more event handlers (onRightClick, onMouseRelease)

With those in I'm my literally just gonna rebuild my entire UI with Eww cause I love it.

Screenshot of my setup at present:

[elkowar]

Looping stuff is planned, and being worked on in the backgorund together with a larger refactor of the state management system. event handlers might be added, as long as gtk allows for them 🤷🏻 if you want anything specific, file a feature request

[VuiMuich]

sorry for sidetracking this, but speaking of loops:
Is there a way of making a button cycle through a list of widgets? I'd like to have an item on my bar that shows either 'layout name', 'window title' or 'media player info' and clicking it cycles through these.
I believe currently this is not possible due to missing some logic options, unless I'm missing out on something..

[VuiMuich]

@elkowar as I am reading more and more about constraints given ba gtk, would it be considerable to move away from it as well?
Maybe OrbTK might be worth a look, I'm not sure though if the are stable enough to be used in a project like eww. Their aim look promising though and match great with eww I believe.

[GoldsteinE]

Proposal: just remove some noice from XML:

def name=something {
  box class={{arg}} halign=start {
    "click this button:"
    button onclick="notify-send 'test' 'message'" {
      "{{some_script}}"
    }
  }
}
var name=some_var { "foo" }
script-var name=some_script interval=1s { "date | sed 's/:/X/g' | rev" }
window name=foo {
  geometry anchor=center width=100px height=10%
  widget {
    something arg={{some_var}}
  }
}

[GoldsteinE]

Optionally, "tags" can have positional arguments, so def name=something can be just def something.

[GoldsteinE]

Also, quotes around tags text should probably be replaced with something else.
Maybe Lua-style [[ strings ]]?

[leotaku]

My suggestion would be to use the Dhall configuration language. It already has a maintained Rust implementation and would also completely solve the need to implement a custom language server or other language tooling (Dhall comes with a language server, formatter, linter and other tools). As a fellow Rust user, I assume you would also appreciate its static type system with excellent type inference.

let some-var = "foo" : Text

let some-script =
      eww.OutputScript::{
      , interval = eww.unit.seconds 1
      , callback = eww.runCommand "date | sed 's/:/X/g' | rev"
      }

let some-widget =
      \(class : Text) ->
        eww.makeWidget
          { class, halign = eww.Layout.Start }
          [ eww.makeTextWidget (eww.staticText "Click on the button!")
          , eww.makeButtonWidget
              { onclick = eww.runCommand "notify-send 'test' 'message'" }
              some-script
          ]

in  eww.makeWindow
      { anchor = eww.Direction.Center
      , width = eww.unit.pixels 100
      , height = eww.unit.percent 10
      }
      [ (some-widget some-var) ]

This is a very naive API example I threw together in a few minutes. In this case, would expect the eww namespace to be automatically added to the prelude of Dhall files used to configure EWW.

Of course this is just my suggestion, I get that the functional OCaml-like style might turn some people off to the idea. Just for the record, I think that using a lisp-style configuration would also be a fine idea, but using Dhall could possibly save you from a lot of uneccessary code duplication in implementing your own language and tooling from scratch.

Cheers! :)

[elkowar]

I mean, eww currently is already a reactive UI framework. As soon as the state changes, the widgets update.

[leotaku]

Hmmmm, I'm sure you are right. I guess my confusion lies in not being exactly sure what degree of control you want to expose to the users of your configuration language. When I made my initial post, I assumed you just wanted to have a better language for arranging and configuring predefined higher-level widgets, whereas I now understand you want to expose more control than that.

In the first case, reactivity can be an implementation detail, whereas in the second case it has to somehow be encoded into the configuration language (i think).

[elkowar]

I mean reactivity means that the users don't set the widget state directly, but have state that automatically updates the widget state once it changes. This means that I need to be able to keep track of where which variables are used, which - in the case of something like dhall - isn't really possible, as usage analysis needs to be part of the language in this case. in XML, given that variables are just not a thing in XML, but are instead implemented on top of it completely separately, I'm able to do that usage analysis there. In a case like dhall, as long as I'd want to still seem clean (thus using dhalls variables, rather than having a weird string-interpolation system or something) that's not possible.

[leotaku]

I think I get what you mean, but I also think that, as long as you don't want to expose lower-level details of your reactive system to the user, you really want to "compile" your configuration language to a static description of your UI that is evaluated whenever your inputs change and drives the UI (both for speed and ease of implementation). This should be possible to implement with Dhall, while a lower-level system would not be.

I also have to admit that I am somewhat out of my depth here. I have never implemented a reactive UI system myself.

[elkowar]

that would be possible if I implemented some type of virtual-dom solution like frameworks like react do. Currently, that's not how it works, and implementing a virtualdom with GTK is,.... not really feasible (it has been done, but doing that would be out-of-scope for eww)

[zx9w]

This kind of discussion is interesting so I am joining but I am not very familiar with eww.. so I don't know what I'm talking about.

From what I can tell from the discussion you will have a turing complete configuration language so I suggest you look into using something pre-existing:

• Guile :: Would be a great choice if you are interested in also using guix (optionally; to ensure dependencies)
• Gamelisp :: Another interesting choice, works well with rust but maybe a bit too powerful?
• Custom :: If you want to roll your own then I recommend EDN or http://people.csail.mit.edu/rivest/Sexp.txt

If you go custom then personally I think the RFC is a better choice because having a canonical representations is so important for cryptography but I am biased because I'm working on (what I hope will be) an XML-killer based on it.

Actually; I'm very interested to see how this project develops, there is some overlap with what I am doing.. what is your communication / state management model?

[VuiMuich]

As this change would be obviously a breaking one (maybe with a possibility to convert configs), I'd like to throw another idea in the room alongside.
From several comments I figured that GTK is kind of a PIA.
Maybe this would be a good chance to leave GTK as well and switch to some native Rust GUI-toolkit.
The two possibilities I just recently stumbled upon, which I think would be interesting would be egui and orbtk.
The biggest downside of both projects as far as my layman opinion allows to tell, probably is that they both are pretty young and will most probably come with future breaking changes on their side as they mature.

Oh and btw: @elkowar do you have a time frame in mind, when you want to settle this whole decision?

[undefinedDarkness]

I dont really see a problem with GTK just yet since umm it works, other frameworks come and go and most alternative frameworks arent as well developed as GTK

[victorbnl]

Something that use tabs, like Pug

eww
  definitions
    def(name='something')
      box(class='{{arg}}' halign='start')
        | click this button:
        button(onclick="notify-send 'test' 'message'")
          | {{some_script}}
  variables
    var(name='some_var')
      | foo
    script-var(name='some_script' interval='1s')
      | date | sed 's/:/X/g' | rev
  windows
    window(name='foo')
      geometry(anchor='center' width='100px' height='10%')
        widget
          something(arg='{{some_var}}')

XML can be converted to Pug easily (actually I just took your code and converted it via a website and fixed some things)

There will probably be problems with the pipes of date | sed 's/:/X/g' | rev so it will need some kind of quoting or escaping

[VuiMuich]

Quote from the opening post

Also:
Given that I hate neither myself nor my users enough for that, I'm definitely_ not gonna do any indentation-sensitive language.

[victorbnl]

Ah sorry (altough it's the easiest for beginners and the most human-readable one)

[VuiMuich]

But also getting one indentation wrong breaks your config and might be even more frustrating for beginners to debug, especially when such a mistake is introduced unaware of an explicit edit (like while reading or scrolling or searching an indentation gets changed).
Such nasty config problems can drive away newcomers faster then you can replay the relevant link to the Guide in indentations in their GitHub-issue, if the even bother to open one..

[victorbnl]

Okip, I understand your decision then!

[elkowar]

I think at this point it's pretty clear that the S-expression syntax is the community (and my) favourite. Edited the original post to reflect that, and I'd say a decision has thus been made!

[undefinedDarkness]

epic

[wiredmatt]

Can you not remove the XML approach in the config file? I'm not a fan of having to rewrite my config files in another language, what I'm asking for is to leave the possibility to write the config in XML.

[VuiMuich]

I believe the idea is to have a conversion tool that tries to translate the config. Maybe this would leave some need for little manual fixes.
Maintaining two configuration languages is really unfeasible, if not impossible as one big intention of moving away from xml is to get rid of some restrictions. So you would have to jump through some hoops to keep both systems working and at the same time go forward with new features in only one of them.
Also giving support on issues with two config-language systems is hell and in the end many solutions two issues will be 'rewrite it in s-expressions'.

[wiredmatt]

A conversion tool sounds fine, I don't think it will be that hard to implement either, thing is my config file is like 2k lines atm, I use eww for a lot of stuff.

[garfr]

elko the lispers have elected you temporary lisp jesus for a day. sexpressions sexpressions sexpressions