• bogwog 23 hours ago
    I too am not looking to move to something that doesn't support Wayland (mostly because of Nvidia, who I doubt will support Xorg forever), but I don't share the negativity in the comments. This looks great, especially since it seems to be part of a larger effort to create a cross-platform UI toolkit (https://fyne.io). The world needs more developers tackling ambitious projects like this, and less OpenAI API wrappers.

    Keep up the good work!

    [-]
  • robert-zaremba 1 day ago
    It's based on X11, unfortunately. I've fully transitioned to Wayland based desktops I would be very happy to try FyneDesk if it would be based on Wayland.

    I see they work on full Wayland support, and targeting to do it in v5.0. What's the ETA? Last release was 1.5 year ago!

    > The 0.4 branch of releases marks the end of X11 native implementations as we will begin the move to Wayland (and XWayland) for 0.5. > https://github.com/FyshOS/fynedesk/releases

    [-]
    • andydotxyz 1 day ago
      Plans shifted due to external factors - the next release will be X11 but after that (later this year) work begins on the Wayland transition.

      Ideally we will support both through the transition but unclear at this time.

    • hu3 1 day ago
      > You can expect work (on Wayland) to begin on that after the upcoming major release. We are waiting on a fix in an upstream library.

      from the Author

    • shrubble 1 day ago
      I was under the impression that there’s a seamless compatibility layer for running X11 under Wayland?
      [-]
      • eadmund 22 hours ago
        Nope, while it is possible to run normal X11 apps under Wayland, there is no support for running X11 window managers.

        Which is a damn shame, because window managers are where some of the greatest innovation is happening.

      • dijit 1 day ago
        Xwayland exists, but you need a compositor to be running to encapsulate the Xwayland container.
    • hyperbolablabla 20 hours ago
      I really dislike the way xdg-desktop-portal works though. Ive been totally unsuccessful trying to implement colour picking in Arch/Hyprland with it. The API is absolutely abysmal
    • hsbauauvhabzb 1 day ago
      Your comment seems very entitled.

      When it’s ready, and faster if you help.

      [-]
      • SpaceNugget 1 day ago
        It's not entitled to not want to try out some new thing if it has major drawbacks over what you are already successfully using.

        If someone randomly comes up to you and offers you an apple with a rotten spot and you say "No thanks, there's a big rotten spot" would you expect them to scold you for being entitled and looking a gift horse in the mouth? _They_ came up to _you_ offering an apple!

        [-]
        • hsbauauvhabzb 1 day ago
          Nobody came up to them though, they opened a hn article that wasn’t posted _for them_, decided the product isn’t for them, which is fine, but then decided to post about how it’s not for them. The project maintainer didn’t ask if the project suited gp, nobody did.
          [-]
          • rootlocus 1 day ago
            Nobody asked anyone anything. It's a post with people sharing thoughts. You don't even know if the maintainer is the same person as the author. As far as feedback goes, if the comment gets enough upvotes it shows a significant number of people share the sentiment, and would be something for the maintainer to consider if he wants a broader audience. Nobody expects the maintainer to respond or care though.
            [-]
            • hsbauauvhabzb 15 hours ago
              That’s like me abruptly telling you I don’t like the way you dress or the shape of your body. Unless you ask, it’s an unwelcome comment.
    • aboardRat4 23 hours ago
      Wayland is a dead end. It will never replace X11 because it's architecture is fundamentally flawed and prone to lags by design.

      It's support for CJK input is also basically broken with no chance of ever getting revived.

      Our best bet on a solid Linux gui lies with XLibre.

      However, saying that, a gui written in Go has very little reason to exist, because we already have excellent GUIs written in lower-level languages.

      If there is anything Linux doesn't lack it it's desktops.

      [-]
      • andydotxyz 23 hours ago
        If you want to code everything in low level languages feel free. I guess assemblers still work well or you can just list machine code.

        For those who want a fast to learn and use higher level language for this Go is a great tool and there are great projects out there. Two of them in the top 10 for all cross platform beating out a lot of other languages (no presence of GTK or Qt up that high... https://ossinsight.io/collections/cross-platform-gui-tool/)

        [-]
        • cozzyd 16 minutes ago
          The metrics on that ranking are super questionable. Not least of which because gtk and QT are not developed on GitHub.
        • aboardRat4 8 hours ago
          >For those who want a fast to learn

          Why would I want something "fast to learn"? That sounds like one of the most ridiculous arguments when choosing a tool to master ever. On the level of "I chose this university because it was walking distance from home".

          I'm choosing a tool I'm going to be using for the next 40 to 50 years. Whether it takes a month or a year to learn makes no difference whatever.

          I want a tool language which is widely portable, so that I could run my programs without rewriting them on as many machines I own as possible.

          I also want them to run as fast, as possible, because I want to run many useful programs on moderate hardware.

          I want to be able to use as many libraries and external utilities as possible, because nobody knows when I might need them.

          It should also work without internet, because who knows when exactly the government is going to cut the wire.

          These core features are what I b would not even consider a language at all. The rest is bells and whistles. Nice to have, but completely optional.

          >Two of them in the top 10 for all cross platform

          I've never heard about any libraries from that list. In any case they seem like tools to write webpages, not tools to write desktop software.

        • LollipopYakuza 21 hours ago
          I would argue that regardless of Go is low-level, for something as fundamental as a desktop environement, a lower level language makes sense.
          [-]
          • andydotxyz 19 hours ago
            I guess that's an interesting opinion to have. Is this based on having built your own desktop environment or some other project that led you to this conclusion?

            For me I prefer higher level code and tooling wherever possible. Building this has been blazingly fast compared to previous window managers I have worked on.

        • vhantz 18 hours ago
          This takes forever to load.
      • antonvs 21 hours ago
        > However, saying that, a gui written in Go has very little reason to exist, because we already have excellent GUIs written in lower-level languages.

        You say that as if it's a good thing. The fact that our platforms depend on C and C++ is not a feature, it's a bug.

  • pjmlp 1 day ago
    For me it could be the foundation of a modern take on Oberon and Inferno linage of operating systems user experience, given how Go came to be, with mix of Limbo and Oberon-2.

    Having the desktop environment, and given Go's stance on dynamic linking (and kind of abandoned plugin package), replace the dynamic behaviours in Oberon and Inferno commands and application extensions, with D-Bus or net/rpc.

    However given the state of desktop fragmentation, most likely it wouldn't be worth the effort, only to get the feeling how it could be like.

    [-]
    • andydotxyz 1 day ago
      My ambition is for it to be the best desktop for developers or people learning to code.

      We are integrating an app editor into FyshOS which (although now renamed and at https://apptrix.ai) can be seen in an old video as a preview: https://youtu.be/XXmDmn-et4E?si=5n1Ao-V6dKurXzS6 (mostly from 15:30 in)

      [-]
      • pjmlp 1 day ago
        Thanks for chiming in, and the link, now I will have to waste some weekends with Fyne Conf content. :)
        [-]
        • andydotxyz 1 day ago
          Perfect :) there are so many great projects and that conference introduces some excellent looking apps.
    • Rochus 1 day ago
      > given Go's stance on dynamic linking (and kind of abandoned plugin package)

      There is indeed a promising alternative to Go plugins which - very similar to the Oberon System - directly loads and runs the object files generated by the compiler: https://github.com/pkujhd/goloader.

      [-]
      • pjmlp 1 day ago
        Thanks for the heads up, have to play around with this.
  • kristianp 1 day ago
    The last commit for the dev branch was 3 days ago, so there is some development still happening. The last merge to main was March 2024, though.
    [-]
    • rowbin 1 day ago
      I think they use master for releases only. Development branch is actively worked on and more than 100 commits ahead of master which is totally active. Last full release March 2024 is totally fine. People can always build from develop branch.
      [-]
      • gouggoug 1 day ago
        Somewhat related...

        At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. We have tons of repositories that follow this pattern.

        For many of them, each branch has taken of its own life and could be considered its own completely different codebase. It's a nightmare to manage and it confuses developers on a regular basis.

        Don't do this.

        If you want to deploy different versions of your software in different environments, use SEMVER and git tags. Don't create 1 branch per environment...

        I have since edited that starter guide and crossed out this recommendation.

        [-]
        • jiggunjer 1 day ago
          It works fine if you review PRs and only allow STG->PRD promotions. It breaks down when people start making separate builds for each env. Treat env as config as you'll just have to manage a config folder in that repo.
          [-]
          • tankenmate 1 day ago
            I concur, it works fine as long as devs follow the procedure. I also prefer to enforce linear history as well so that git bisect works properly; but then this requires devs to understand how to use --ff-only and also if you're using github to use a github action to fast forward as github doesn't natively support fast forward (one of github's many sins).

            But then I also find I need to train devs on how git actually works and how to use git properly because I find that only about 10% of devs actually understand git. But it works out best for everyone once all the devs understand git, so generally most devs appreciate it when someone is willing to teach them the ins and outs (but not all devs appreciate it before they learn it properly though).

            As always though, it's trade offs.

            [-]
            • jmmv 1 day ago
              You can configure branch protections in GitHub to rebase during PR merges and enforce a linear history.
            • brabel 1 day ago
              Sorry but you are just using source control very wrong if you keep 2 parallel environments in the exact same code base but different branches. The build itself should know whether to build for one environment or another!
              [-]
              • tankenmate 1 day ago
                They are the same only sometimes; devs work on code on feature / fix / whatever branch, then when they've finished dev testing you do a code review and then it gets fast forwarded onto the dev branch, then when it suits for staging (non dev team stakeholder testing / infra testing) it gets fast forwarded to staging, then when it passes staging testing (if necessary), then it get ff onto prod and deployed. so dev will sometimes point to the same commit as staging but sometimes not, and staging will point to the same commit as prod but sometimes not. It's a funnel, a conveyor belt if you will.
                [-]
                • brabel 21 hours ago
                  Yes I know. That's not how they said they are doing it.
              • jiggunjer 1 day ago
                Sorry but you building wrong if you need separate builds.
                [-]
                • skydhash 23 hours ago
                  Mobile apps release process will disagree with you. there’s a gap of around 4 days between what you consider as a release and what can be on prod. If you got rebutted by review, you need to edit the code. If you want to rollback, you need to edit the code. You can only be linear if you control releases.
        • ezst 1 day ago
          > For many of them, each branch has taken of its own life and could be considered its own completely different codebase.

          Seems you have bigger process issues to tackle. There's nothing inherently wrong with having per-env branches (if one thing, it's made harder by git being so terrible at branching in the general/long lived case, but the VCS cannot alone be blamed for developers consistently pushing to inadequate branches).

          [-]
          • gouggoug 21 hours ago
            > There's nothing inherently wrong with having per-env branches

            There is when you stop thinking in terms of dev, staging and prod, and you realize that you might have thousands of different environments, all named differently.

            Do you create a branch for each one of them?

            Using the environment name as branch name is coupling your repository with the external infrastructure that's running your code. If that infrastructure changes, you need to change your repository. That in itself is a cue it's a bad idea to use branches this way.

            Another issue with this pattern is that you can't know what's deployed at any given time in prod. Deploying the "production" branch might yield a different result 10 minutes from now, than it did 25 minutes ago. (add to the mix caching issues, and you have a great recipe for confusing and hard to debug issues)

            If you use tags, which literally are meant for that, combined with semver (though not necessarily a requirement, but a strong recommendation), you decouple your code and the external environment.

            You can now point your "dev" environment to "main", point staging to ">= v1.25.0" and "prod" to "v1.25.0", "dev-alice" to "v2.0.0", "dev-john" to "deadb33f".

            When you deploy "v1.25.0" in prod, you _know_ it will deploy v1.25.0 and not commit deadb33f that so happened to have been merged to the "production" branch 30 seconds ago.

          • zx8080 1 day ago
            > if one thing, it's made harder by git being so terrible at branching in the general/long lived case

            Interesting. What's wrong with branching in git?

          • skydhash 23 hours ago
            Branch is semantic. The true unit is commit and the tree is applying a set of commits. Branching is just selecting a set of commits for a tree. There’s no wrong or right branch, there is just the matter of generating the wrong patch
            [-]
            • gouggoug 21 hours ago
              Branches are mutable and regularly point to a new commit. Branching is selecting an active line of development, a set of commits that change over time.

              That's why git also offer tags. Tags are immutable.

              That's an important distinction.

        • overfeed 21 hours ago
          > Don't do this

          There are multiple valid branching strategies. Your recommended strategy works well[0] with evergreen deployments, but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs.

          0. Semver uas many issues that I won't repeat here, mostly stemming from projecting a graph of changes onto a single-dimension.

          [-]
          • deepsun 19 hours ago
            I always thought multiple hardware targets are solved by build flags. And keep the one branch. E.g. in Go you can include/exclude a file based on "build tags":

            https://www.digitalocean.com/community/tutorials/customizing...

          • gouggoug 18 hours ago
            > but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs.

            I don't have experience in this world, indeed.

            But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? The application code is the same (same version), the configuration (which is external to the application) is different.

            Your build system takes your application code and the configuration as input, and outputs artifacts for that specific combination of inputs.

        • j1elo 22 hours ago
          "At company x, they had a kitchen and a couple meeting rooms. Devs started using the rooms for cooking, and the kitchen for team standups."

          Tools are just there, it's people who misuse them. If devs at company x are incapable of understanding that you shouldn't be cooking an omelette in the meeting room, to be honest that's on the dev, not on the separation of concerns that was put there for them.

          Probably what's missing there is training to set the expectations, policing on their actions, and a soft reprimand when the typical first time mistake is done. But if the metaphorical rooms have no indicators, no name tags, and no obvious usage guidelines, because no one bothered to set them up, then yeah expect board meetings to end up happening in the kitchen.

          [-]
          • gouggoug 21 hours ago
            > Tools are just there, it's people who misuse them.

            Absolutely. And it doesn't help when people write guides actively encouraging mis-using tools

        • kardianos 1 day ago
          Generally agree. All changes for me are cherry-picked to master only.
      • repeekad 1 day ago
        Reminds me of when someone at the company didn’t like the branch master so they unilaterally directed their team to start working on “main”, resulting in a massive merge conflict that took over two weeks of dedicated effort to resolve, ugh…
        [-]
        • IshKebab 1 day ago
          That's hilarious. I'd be so pissed if I was their manager (or their manager's manager).
        • DagsEoress 1 day ago
          Brainless politics ruined coding
    • gjvc 1 day ago
      usual passive-aggressive HN comment on someone's effort
  • cfn 1 day ago
    This actually looks quite good for a brand new development. I am big fan of vertical docks but that vertical time...
    [-]
    • sgc 1 day ago
      Last update to master was last year, develop not much more going on. It looks like it was started 7 years ago.
      [-]
      • andydotxyz 1 day ago
        In the last few months we have added a built-in compositor, a new screensaver, file manager integration and a bunch of optimisations. Seems like pretty decent progress to me.
      • Cthulhu_ 1 day ago
        Master isn't the development branch though; you want these things to be fairly stable.
        [-]
        • sgc 1 day ago
          The 'develop' I mentioned is the name of their development branch. Regardless, one of their contributors made a couple sibling comments in this submission indicating there is more work going on than immediately visible by quickly looking at commit timestamps - which I am happy to hear.
    • bmicraft 1 day ago
      New? It doesn't even look like it supports Wayland.
  • pablo1 1 day ago
    Wayland is a must for me at this point. If it starts supporting it I will give it a serious try
    [-]
    • andydotxyz 1 day ago
      You can expect work to begin on that after the upcoming major release. We are waiting on a fix in an upstream library.
    • brabel 1 day ago
      Honest question: why? I tried Wayland for a while but couldn’t tell what is different about it as just a user.
      [-]
      • gorgoiler 1 day ago
        Not OP but seamless (tearfree) rendering and fractional scaling for displays are the two big goodies, for me.
        [-]
        • andydotxyz 24 hours ago
          Ironically we have both of those on this Fyne Desk running in X.

          Tear free is provided by the compositor and the fractional scaling was never impossible with X it just had to be coded into the toolkit and most could not be bothered. Fyne has always supported fractional scaling and I think Enlightenment does too.

      • pacifika 1 day ago
        Search for Wayland I think the debate is not new.
  • gwbas1c 24 hours ago
    I'm trying to understand who is behind this and what their motivations are. Is this developed as a hobby, is this part of a for profit venture, an academic project sponsored by a university, or ...?

    The best I can find is the parent Github account, which has two users: https://github.com/FyshOS

    [-]
    • andydotxyz 24 hours ago
      The project is being developed as a volunteer open source project because we think it should exist. There are 4 core members on the team https://github.com/orgs/FyshOS/people but we accept contributions from around the community.

      We are always looking for sponsorship and of course commercial partnerships would be pretty cool too!

      [-]
      • asmor 23 hours ago
        Just FYI, there's only two members who are visible if you're not in the organization yourself.
        [-]
        • andydotxyz 23 hours ago
          Oh that is strange, I didn't realise it was different for internal vs external! I fixed my visibility but one of the team is marked as private for their own reasons.

          Basically the project came from the Fyne community because we can build all GUI apps so fast now that it was a shame not to have a desktop environment with the same benefit :).

          [-]
          • williamDafoe 19 hours ago
            So to summarize - Fyne is a (? cross-platform ?) library for GUI apps, and you believe it's more productive than existing libraries, so you wanted a native window manager because ... exactly why? what exactly is the savings or advantage?
            [-]
            • andydotxyz 19 hours ago
              Because I tried working on existing ones and it was painful.

              I wanted a modern alternative to exist that was approachable and fun. And once we have met existing systems we can start to exceed them ;).

  • jamesnorden 1 day ago
    If anyone else was wondering, after some digging around, I confirmed you can change the window decorations/buttons to the right side, seems like that was added on version 0.2.
  • giancarlostoro 1 day ago
    Oh man. This is really interesting. Might have to try it out. I have been experimenting with Fyne and like it. Been wanting to mess with customizable DEs but hate the whole headache of setting most up. Go makes things doable for me.
    [-]
    • andydotxyz 1 day ago
      Yes give it a play - we are trying to make it super easy to get into developing on the desktop environment.

      For example the modules on the panel or desktop are basically just functions that return a `fyne.CanvasObject` so it's basically just like making a panel in a Fyne app :).

      [-]
  • jjoe 1 day ago
    Will definitely give it a shot this weekend. Any known quirks to be aware of on Pop!_OS 22?
  • oflebbe 20 hours ago
    I played with fyne some months ago. Binaries are gigantic and what does drive me crazy it is consuming cpu all the time even if it should stay idle
    [-]
    • andydotxyz 19 hours ago
      Any known CPU usage bugs have been resolved. Last time it was the cursor animation but we fixed that too. I can now compare our apps to OS provided native equivalents (we're not there yet but it is getting close!)
  • omgmajk 1 day ago
    Previous discussion: https://news.ycombinator.com/item?id=40011100 (2024, 64 comments)
  • koeng 1 day ago
    Neat. I wonder what performance is like compared to normal desktop environments.
    [-]
    • gigatexal 1 day ago
      Probably better than Gnome’s single threaded-ness.

      I bet it’s smooth given how concurrent friendly Go is with channels and go routines etc.

      [-]
      • matttproud 1 day ago
        Seriously. I don't know if folks remember this Java desktop research project from 25-some years ago: https://en.wikipedia.org/wiki/Project_Looking_Glass. To say that it was slow was an understatement (it was a real PITA to get this installed and built at the time; I spent an afternoon in college doing that out of boredom).

        I imagine FyneDesk is plenty fine for what it is doing in comparison.

        [-]
        • pjmlp 1 day ago
          I do, this was a research project.

          Also this was mostly interpreted back then, without JIT compiler support.

          Also to note,

          > Regardless of the threat, Sun determined that the project was not a priority and decided not to put more resource to develop it to product quality. The project continued in an experimental mode, but with Sun's finances deteriorating, it became inactive in late 2006

          Written from a Java userspace powered mobile phone, with 75% worldwide market share.

        • andydotxyz 1 day ago
          That was a really cool project but yeah the Java couldn’t hack it.

          FyneDesk aims to compete on performance with the light weight window managers whilst offering the rich experience of complete desktops.

          We are close on performance in most areas, once Fyne v2.7.0 is out we will do a new release which is going to blow our previous out of the water. Just a few thread handling bugs to iron out for optimal results first…

          [-]
          • pjmlp 1 day ago
            Java is fast enough for having legions of kids playing games written in it, and a full OS userspace, it is a matter of implementation, and how much use gets done in JNI, no different than reaching out to CGO or Plan 9 Assembler, while keeping most of the code in Go.
            [-]
            • andydotxyz 1 day ago
              Oh yes, I didn’t mean to knock the language - I also worked on amazing things in Java before I moved to go.

              But the runtime of a Go app is, by default, faster than Java and my experiences have shown much, much better performance with the sort of multi-window full screen throughput we need for building a desktop.

        • radicaldreamer 1 day ago
          The Project Looking Glass UI came to iPadOS and MacOS via Stage Manager https://support.apple.com/en-gb/guide/mac-help/mchl534ba392/...
          [-]
          • ffsm8 1 day ago
            youre implying that Stage Manager is Java. I dont think thats true though?

            Isnt it only the _design_ of stage manager somewhat resembles some design choices by project looking glass?

            this design has also been adopted by the other OS's like windows+tab has previously (in win7 days) created a similar looking view - though it no longer looks like it nowadays.

            [-]
            • heavyset_go 1 day ago
              > this design has also been adopted by the other OS's like windows+tab has previously (in win7 days) created a similar looking view - though it no longer looks like it nowadays.

              Looking Glass-like switchers are still available in Plasma

            • bestham 1 day ago
              The Project Looking Glass UI != The Project Looking Glass They are talking about the UI which could have inspired Stage Manager. Apple also had the purple window button before Project Looking Glass so there is that.
        • blauditore 1 day ago
          > [...] that Apple would sue Sun if they moved forward to commercialize it – Jobs felt the project infringed Apple's intellectual property.

          Classic Apple.

          [-]
          • p_l 1 day ago
            Jobs dropped such suggestions after he was informed Keynote would get hit back
      • SkiFire13 1 day ago
        Multithreading doesn't automatically make stuff smooth. It allows you to increase throughput, but it can also increase latency if don't have enough work or you split it too much.
      • sapiogram 1 day ago
        > I bet it’s smooth given how concurrent friendly Go is with channels and go routines etc.

        You can do the same in any language with threads, and a library providing channels. Hell, you could probably do it better with a library, go's channels are unnecessarily error prone with nils, channel closing, and cleanup behavior.

        [-]
        • tsimionescu 21 hours ago
          While I agree on channels, you can't easily reproduce the behavior of Go's threads in other languages. The whole Go IO library is built with support for Go's green threads. The result is that 1000 Go threads waiting on IO operations will actually issue only a handful of OS non-blocking IO calls and have the runtime handle polling and waking up the right threads.

          Not sure how relevant this is for UI operations, to be fair. The C#/JS style async/await model actually seems more amenable to controlling which works happens on the necessarily single GUI thread and which parts happen in background threads, and how to sync them later.

      • munchlax 1 day ago
        What are you guys doing with your desktop environment that you need it to be performant and multithreaded?

        Aren't all computers plenty fast enough now?

        [-]
        • robinsonb5 1 day ago
          You'd think, wouldn't you? But in some regards they still feel less responsive than the desktop of a sub-10MHz machine from the 1980s.

          (I'm not kidding - the tight coupling of quadrature-based mouse counters and hardware sprite mouse cursor - bypassing all the wireless, serial / PS/2 / USB encoding and decoding we have today - and on-screen gadgets being drawn and redrawn in the input subsystem's context without messages having to trickle through a ten foot long pipeline of frameworks and UI toolkits, all gave a sense of immediacy, of "having the computer's full attention", that's rare to find in today's world of janky semi-functional web apps.)

        • Twirrim 1 day ago
          They should be, but with the speed and resources available on machines these days, people don't spend as much time optimising every little thing, and even make trade-offs, e.g. Gnome 3 desktop has the spidermonkey javascript engine in it, and an increasing numbers of components are using javascript.
        • pjmlp 1 day ago
          Depends on how much Electron crap is running alongside the desktop.
        • shmerl 1 day ago
          Not necessarily the environment, but compositor itself must be fast. It shouldn't introduce any delays that would affect for instance input latency in its processing loop. Gamers would for sure complain.

          Someone could totally make it do everything in a single thread and not think about that, which would be pretty bad.

          [-]
          • winrid 1 day ago
            That doesn't require multi threading.
            [-]
            • nasretdinov 1 day ago
              On a high enough resolution, especially with 5K-6K displays a single-threaded software-only compositor is absolutely going to have horrible performance. Even on Full HD it's actually quite noticeable
            • shmerl 1 day ago
              If it does almost nothing - may be not. Otherwise you'll be doing something in the main thread which will take time, unless you also squeeze concurrency (i.e. multitasking) into one thread and then again, why not use multiple threads already.
        • wiseowise 1 day ago
          “Don’t you guys have fast computers?”
          [-]
          • munchlax 1 day ago
            My computers are old and slow.

            They run XFCE just fine.

        • gigatexal 1 day ago
          We are called power users ;-) we can do more than one thing or ten things at a time and want things to be responsive and fast and not drop frames and not crash the whole session when some plugin fails etc etc. you know, a well designed thing
    • pjmlp 1 day ago
      I bet running circles around the JavaScript mess of GNOME.
    • ikiris 1 day ago
      Based on the name its probably based on Fyne... Last time I tried to use fyne was not great. They overly fixate on mobile first to the detriment of any other platform.
      [-]
      • andydotxyz 1 day ago
        Fyne has never been focused on mobile first - it is platform agnostic. Desktop performance is incredibly fast and mobile performance is nearly as good (Fyne v2.7.0 will deliver a huge speed boost this month). If you haven’t tried it in a couple of years I highly recommend you give it another go.
        [-]
        • nickcw 1 day ago
          I'm looking forward to the v2.7.0 - I think this will fix the glacial scrolling on Android which is great!
        • ikiris 22 hours ago
          This is also the type of response you’ll get if you bring up any issues. Their marketing people will come argue with it instead of trying to fix things. I basically gave up dealing with them and went back to suffering through qt. The project looks promising and I’d love to use it but the actual experience is regret every time I’ve tried.
          [-]
          • andydotxyz 22 hours ago
            I don't understand this - are you calling me a marketing person? I started the project and continue to do most of the coding. Feel free to tell me I don't know what I am talking about but I would like to know more what we can do to dispel the idea of being mobile focused...
  • sam_lowry_ 1 day ago
    X or Wayland?
    [-]
    • shmerl 1 day ago
      It seems to rely on compton so no Wayland I guess, which makes is an interesting toy, but not a serious option.
      [-]
      • andydotxyz 1 day ago
        Latest commits on develop replace Compton with a builtin compositor.

        Ready for a wayland support to begin after the next release!

      • em-bee 1 day ago
        it uses fyne.io, which supports wayland as of version 2.5.

        and it also says that it runs without those runtime dependencies, except that the experience will be degraded. so the question is how degraded, and what will it take to fix that?

        [-]
        • andydotxyz 1 day ago
          The compositor external dependency was really just an experiment and we replaced it already. You can still turn of compositing but it does offer better speed for tabbing around windows and also means you can make each transparent independently :).

          The new default is that background windows become slightly transparent.

          https://www.dropbox.com/scl/fi/8o0tmimx09pwak2h0lfi0/fynedes...

          [-]
          • em-bee 23 hours ago
            compositing is not the issue but as others have mentioned dependency on X11 is. i look forward to be able to try it when it works with wayland. but don't let us pressure you. it will be ready when it's ready. not earlier.
        • shmerl 1 day ago
          I see, that's good.
  • laurent_du 23 hours ago
    I have been a Linux user for 20 years and I have no idea what display server or windows manager I use. Every time this theme pops up on HN a lot of people argue very passionately about this and I feel I have no understanding at all of this. What are the stakes? Why does this matter? Why is there so much argument going on around Wayland, Xorg, X11 and whatever?
    [-]
    • lugu 15 hours ago
      I guess it is like cars, some drive them, and some like to open the hood. That make a nice topic for discussion because we can all share anecdotes of broken stuff on Linux desktops. Same for Emacs/vim, instead of sharing what we are programming, we complain/argue about editors, because they are the shared experience we have in common.
  • AlienRobot 23 hours ago
    What does this do (or will it do) better than existing DE's?
    [-]
    • andydotxyz 23 hours ago
      It is really easy to code on, supports lots of different platforms (including embedded and mobile devices). Some times established projects can be superseded with newer ones build with more modern tools. I get that feeling in this space and it's huge what has been built already.
  • rudderdev 1 day ago
    Looks promising. Will try this weekend. Any tips to quickly try it out?
    [-]
    • andydotxyz 1 day ago
      Just make and make install in the root of the source is easiest then log out and pick it from your login screen.

      However if you want to try it in development mode you can “make embed” to try it in an embedded X session.

  • danielspace23 1 day ago
    Fyne is an interesting library, and although I'm sure it can do a good job on the desktop, last time I tried it I was disappointed by how "meh" it works on mobile (Android in my case).

    It does run, but I feel like it's more of a prototyping tool, or a tool for building internal apps. It's kinda slow, graphically inconsistent with the rest of Android, and it has little to no support for features like foreground services, the camera, and more.

    I really hope they can improve, but with limited resources and funding, and such a wide scope, I'm not sure if they will ever be ready for more complex projects. In any case, best of luck to the devs!

    [-]
    • andydotxyz 1 day ago
      Please check out v2.7.0 - the optimisations for mobile are amazing.

      Camera and services are coming in another release - work has begun.

      It's amazing what has been done with virtually no funding - if anyone would consider sponsoring then truly incredible things could be delivered :).

  • gjvc 1 day ago
    god i would love a sensible windows 2000 or macos 10.6 desktop right now
  • ingen0s 1 day ago
    Nice werk
  • scottydelta 1 day ago
    [flagged]
    [-]
    • jamesnorden 1 day ago
      So true, 3 days without commits is too much.
    • hu3 1 day ago
      Perhaps you could use some tips on using GitHub.
    • gjvc 1 day ago
      who is "we" and are you part of "them" ?