1. 41
  1. 5

    I never heard of this project and it is very impressive. The demo videos show there’s a lot of potential, but looking at the feature list (shaders, 3D models and picking) it seems almost too good to be true. There’s no API documentation, so it’s hard to get an idea of its architecture and what it can really do.

    1. 9

      but there’s a lot of it. https://github.com/letoram/arcan/wiki particularly the ‘developer information section’. The API itself also has offline documentation as part of the doc folder in the git repo.

      1. 5

        Thanks for pointing this out, it does indeed contain a lot of information. Given that you’re an Arcan developer, I wanted to ask you: how do you see Arcan with respect to Xorg and Wayland from a end-user desktop perspective? From my current basic understanding, Arcan seems like a very versatile framework for creating interactive interfaces, which seems to even allow for the embedding of Xorg or Wayland applications. Do you envision people creating new desktop interfaces (maybe a 3D desktop interface) that integrate both existing 2D applications (like GTK apps) and completely different/innovative UIs?

        1. 6

          Well it’s complicated and political, I have a more end-user targeted post (the ‘near finished draft’ bin is about 11 articles here) that dives into it and my own motivation - I’m patiently waiting and keeping the really cutting edge stuff to myself. Recall that this ‘for the fun’ PoC ( https://youtu.be/3O40cPUqLbU?t=146 ) was about the state 5 years ago.

          But the intent was indeed for other custom UIs - see the high level presentation from a while back ( https://www.youtube.com/watch?v=07nqZIFRDJg ), and I’ve <names / details redacted> commercial clients that are using it as a base for quite interesting things.

          In terms of new desktop interfaces and 3D, did you see https://www.youtube.com/watch?v=Js7Y1H5D8cY ? :-)

          1. 5

            Yes, and I was thinking of Looking Glass and BumpTop. I think using Lua as the language for implementation is a smart choice, as it makes experimentation and prototyping much more accessible. Can’t wait to read your end-user post!

            1. 2

              Problem with those is that they fall in the ‘cute, but mostly useless’ part, I think the big blocker for real / better UIs like that is that the input devices are so poor and so hard to retrain people from relying on. My current experiments here use an eye tracker instead, and oh boy does that make a difference.

              That particular cleverness was mostly Blizzard (there’s more in the API design though..) as I took the cue from World of Warcraft back when it was in Beta. They have an interesting threat model and quite complex UIs. Other than that, I appreciate the Lua VM design, minimal runtime, implementation and API - not so much the language itself, but it’s tolerable and “mostly harmless” (unlike say, javascript, python and the likes) as a policy language.

      2. 6

        crazylogad has done a few submissions on this if you want to read more.

      3. 4

        A client may negotiate for additional segments, but these can be rejected, and rejection is, just as in real life, the default behaviour.


        1. 2

          Regarding window decorations, IIUC they’re done on WM side; that’s awesome by default, but also seems to disable any chance of innovation in this area (e.g. Windows Ribbon, whether one likes it or not). Is there some way to opt-in to such approach?

          Also, sorry if that’s a stupid question, or answered elsewhere, but does Arcan provide some standard “widgets library” for common elements?

          1. 8

            I tried to cover that, but a lot of these things take much more thorough explanation. On a high level, think like this:

            1. Client connects, gets its context and starts drawing. WM decorates.
            2. Client requests a ‘titlebar’ area decoration.
            3. WM gets the request - and the option to say ‘yes’ or ‘no’ depending on if it fits into its decoration model or not.
            4. Client gets the response, if positive, maps it ands starts to draw into it - if no (default) prepare a UI that doesn’t require it.

            This allows the GTK like fat-fingers-bars, but doesn’t go the really dumb route of assuming that a client HAS to provide border, shadows and mouse cursors. It is also segmented so that any server side features (like recording, sharing, exposé like overviews, ..) can drop the decorations to not mess with compression schemes or break filtering by mixing contents of different origins.

            The ‘widget library’ is no stupid question – if you look into the related durden DE project, the standard widgets there are slowly evolving and in a way that will be lifted out and shareable, I’m just not at the state where that is a good idea.

            1. 1

              Ok, thanks for the info! That’s great :)

              From looking at Durden, I understand “widgets” there are of “non-standard” paradigm, i.e. no “checkboxes etc.”, but “HUD menu”-based. Is that correct?

              By the way, whenever your work surfaces again on HN or here, I always find the work and your dedication amazing, mindblowing and inspiring. Thank you for that! :)

              1. 2

                Ah sorry, I see the confusion. There’s actually three ‘widget’ senses used here. The toolkit “checkboxes etc.” part which is the binding bar, toolbar / statusbar (same thing) and the navigation bar (the HUD itself), as well as popup menus. This one is deliberately quite limited as I avoid toolkit style UIs like the plague they are :-)

                The other two are what is meant in the Durden documentation and UI language - the main one is the ‘HUD elements’ sense. There is a yet to be used other definition where clients themselves allocate subwindows to provide a simplified summarised ‘fixed frame’ like representation of itself (statusbar and desktop icons work in the same way).

                Also, thanks for noticing.

                1. 1

                  Still somewhat confused; so, no checkboxes? Or yes checkboxes? :) Do you maybe have some kind of a screenshot showing all that’s available in this domain in Arcan/Durden? I tried to browse through the videos, but didn’t seem to notice too much like that; mostly seem to me to be videos & games, and TUI apps… do you have some, dunno, image painting app? audio editing app? any creative non-TUI app?

                  edit: I mean, with interface built purely on what’s available in Arcan/Durden, not using GTK/Qt/…

                  1. 2

                    I think I get what you mean - non-TUI apps are a few contracting ones I don’t have permission to present or at least not yet (VR etc.), along with the senseye stuff and so on. All the API design and focus has been on providing lower level primitives so they are not on the level of:

                    checkbox = new_checkbox("hi there")

                    but the step beneath that:

                    checkbox = {null_surface(32, 32), false}
                    checked = load_image("checked.png")
                    unchecked = load_image("unchecked.png")
                    image_sharestorage(unchecked, checkbox[1])
                    label = render_text("hi there")
                    link_image(label, checkbox, ANCHOR_UR)
                    name = "checkbox_listener",
                    click = function()
                        checkbox[2] = not checkbox[2]
                        image_sharestorage(checkbox[2] and checked or unchecked, checkbox[1])
                    own = function(ctx, vid)
                        return vid == checkbox[1];
                    show_image({label, checkbox[1]})

                    Just pulled out of thin air but should pretty much be it. So the icons, toolbars, popups, listview etc. in this (very) old clip https://www.youtube.com/watch?v=3O40cPUqLbU written in the latter style. That’s what I meant with that there are a few examples but not generalized to the first form and packaged / distributed.

                    Reason is time/motivation, but even more - what will be fleshed out in the coming article, but is hinted at in this one:

                    The philosophy behind the design is to let the server side absorb systemic complexity, and strive to make clients as trivial as possible to both develop and inspect. No multi-million lines of code toolkit should ever be necessary. The perspective is to instead emphasise the extremes, that is to focus on the small “one task” kind of clients and on integration with bigger “embedded universes” like virtual machines and web browsers, and leave the middle to fester and rot.”

                    Better “desktop IPC” to segment the simple clients so that they aren’t modelled around interactive UI components as more mechanisms to modify, share and compose visual/aural typed data. But again, it’s a long story.

                    1. 1

                      Oookay, now it’s finally clear to me at what level of abstraction this fits. Thanks for patience and caring!!!

          2. 1

            This was a bit too long and outside of my technical area of expertise to read fully, so forgive me, but could you answer a simple question: does this software also replicate the “feature” of X server where any app can listen to keystrokes of other apps?

            1. 2

              The input model requires the WM to ‘“route” all inputs, an app doesn’t “grab” input like in X so a client receives no input unless the WM specify exactly which ones.

              1. 1

                I’m sorry I don’t understand your answer. Can you give a yes or no answer to this:

                does this software also replicate the “feature” of X server where any app can listen to keystrokes of other apps?

                1. 1

                  That’s a no. To any app. You can chose to give some apps that capability.

                  1. 1

                    When you say “you can choose”, who is the “you” of that sentence? The developer? Or the user? And how does it work in practice?

                    1. 1

                      both (assuming some amount of code literacy), but part of the point is making WM modifications “bash-scripting” levels of difficulty, not the crazy stuff needed for Xorg or WL. Take this example of a minimal wm”:

                      local clients = {}
                      function mywm()
                          local alloc_fn;
                          alloc_fn = function()
                              function(source, status)
                                  if status.kind == "resized" then
                                      resize_image(source, status.width, status.height)
                                  elseif status.kind == "terminated" then
                                       clients[source] = nil
                                  elseif status.kind == "connected" then
                                       clients[source] = true
                      function mywm_input(iotbl)
                          for vid,_ in pairs(clients) do
                              target_input(vid, iotbl)

                      I havn’t tested this exact code but it is about what is required for a ‘dumb’ WM where clients can connect like ARCAN_CONNPATH=“mywm” afsrv_terminal; (included terminal emulator).

                      Notice the way the mywm_input function is written now. Every time the engine manages to get input from any input device (keyboard, mouse, game, …) all clients can read it. If you change it to track say a “selected” window and only send to that, well, only that client will get the input.

                      1. 1

                        So… you’re saying that it depends on the window manager? Some might allow keyloggers and others might not?

                        If my window manager has code to prevent key loggers, can another app I run still get access to the keys using your APIs?

            2. 1

              @crazyloglad, does anyone use Arcan on “production” (both embedded or desktop-wise) or just for daily use?

              I’m really interested on how “mature” and usable Arcan currently is.

              1. 3

                Embedded programs in production, yes.

                There are two commercial projects (actually the reason for the 0.4 lts branch and some of the financing a while back) that has been running it (afaik) non-stop for multiple years. One embedded UI and one machine-vision/automated testing facility. There are ~3 projects being developed outside the ones I have. Other versioning schemes would have it passed ‘1.0’ maturity wise a while back.

                Desktop use, not that I know. Durden isn’t user-friendly enough (and not intended as such, that story is in the 6mo-1year timeline). Compatibility story also isn’t good enough (not a priority – features first, then compatibility). Xarcan runs X clients as a ‘fully contained, VMM style’, arcan-wayland runs Wayland clients and in the dev-branch, maps Xwayland clients. If the Wayland ecosystem doesn’t improve (little points to that) very soon, the compatibility strategy will be adjusted.