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.
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
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
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/)
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.
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.
I prefer higher level code and tooling wherever possible
exactly this.
go actually strikes a balance of being one of the few high level languages that can compile directly to binary. there are not many languages that can do that. common lisp, erlang, o'caml and maybe red are a few others that i am aware of. there are probably a few more that are less popular that i don't know.
for me high level implies at least automatic memory management and high level data types.
I mean much of gnome shell is written in JavaScript. But of course GTK is C.
Does Fyne have bindings to other languages? A search for fyne python gave some hilarious AI slop from Gemini suggesting pip install fyne, but the fyne python package is something completely different and unrelated. The nice thing about GTK is it can be used from virtually any language (QT a bit less so but still a lot)
No. Fyne does not have any bindings and never will in the official project.
The API is designed to work perfectly with the Go idioms and using it from any other language will be no where near as intuitive. Not to mention it would slow down the developers of the toolkit as well!
First of all cool concept. I'm looking forward to playing with the DE even if it doesn't replace my daily DE.
In my experience, extending an existing project in Go is much faster than lower level languages. The opinionated build and dependency system can seem limiting but really helps one get up to speed quickly on a new project.
Just setting up a build environment for a low level language based project can be enough of a hassle/time sink to dissuade me from attempting with a quick toy project.
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!
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.
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.
actually, it's more like you are selling clothes, and i don't like the style, and i am telling you which style i'd like to buy.
you don't have to produce my style, and i don't have to buy your clothes, but it's good to talk about our preferences so you have a better idea of the potential market.
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.
> 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.
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.
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.
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.
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).
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!
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.
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.
> 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).
> 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.
Before git abused the terminology, a branch used to refer to a long-lived/persistent commit lineage, most often implemented as a commit-level flag/attribute,
OTOH, git branches are pointers to one single commit (with the git UI tentatively converting this information sometimes into "that commit, specifically" or sometimes as "all ancestors commits leading to that commit", with more or less success and consistency).
Where it matters (besides fostering good/consistent UX) is when you merge several (topological) branches together: git won't be able to tell if you just merged A into B or B into A. Although the content is identical at code-level, the semantic/intent of the merge is lost. Similarly, once the head has progressed so much ahead and your history is riddled with merges, you can't tell from the DAG where the individual features/PR/series start and end. This makes bisecting very hard: while hunting down a regression, you would rather avoid checking-out mid-series commits that might break the build, and instead stick to the series boundaries. You can't do that natively with git. That also makes maintaining concurrent versions unnecessarily difficult, and many projects are struggling with that: have you seen for instance Django¹ prefixing each and every commit with the (long-lived) branch name? That's what you get with git while most other VCSes (like Mercurial, my preference) got right from the start.
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
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.
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.
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":
> 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.
> But isn't "multiple release versions of an app" just "one application, with multiple different configurations"?
That would be nice (and evergreen), but that's not always the case. It's common to have different versions of the app released simultaneously, with different features and bugfixes shipped.
Think of Microsoft simultaneously supporting Windows 10 and 11, while still releasing patches for XP: they are all individual OSes that share some common code, but can't be detangled at build times[1]
The customer will be reluctant to upgrade major versions due to licensing costs and risk if breakage (your code, or their integrations), but still expect bugfixes (and only bugfixes) on their deployed versions, which you're contracted to provide. Using the evergreen approach.
I'm not convinced using build flags to manage which code is shipped is superior to release branches, I fall on the side of release branches because using bisect is invaluable.
1. I suppose as long as the build system is turing complete, one could hypothetically build Windows XP, 7, 8, 10 and 11 off the same codebase using flags. I would not envy that person.
"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.
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…
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.
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.
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?
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.
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.
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.
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 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!
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 :).
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?
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.
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 :).
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.
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.
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.
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…
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.
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.
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.
> 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
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.
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.
> 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.
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.
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.)
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.
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.
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.
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
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
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.
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.
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.
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...
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!)
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?
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.
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.
You like fyne a lot, huh? I started writing a desktop app with it but got stuck, it can't really do very nice tables and the styling is not flexible enough for me
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!
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!
> that doesn't support Wayland
Dont know what the state is but they work on it
https://github.com/FyshOS/fynedesk/issues/76
Amazing comment and thanks for the support!
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
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.
> 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
I was under the impression that there’s a seamless compatibility layer for running X11 under Wayland?
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.
X11 window managers are replaced by wayland compositors. they are more complex, but multiple alternatives already exist.
Sure, but those are not backwards-compatible. If Wayland let me run my existing window manager then I would be glad to try it out.
i am responding to "window managers are where some of the greatest innovation is happening"
innovation is happening with compositors too.
Xwayland exists, but you need a compositor to be running to encapsulate the Xwayland container.
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
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.
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/)
>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.
The metrics on that ranking are super questionable. Not least of which because gtk and QT are not developed on GitHub.
I would argue that regardless of Go is low-level, for something as fundamental as a desktop environement, a lower level language makes sense.
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.
I prefer higher level code and tooling wherever possible
exactly this.
go actually strikes a balance of being one of the few high level languages that can compile directly to binary. there are not many languages that can do that. common lisp, erlang, o'caml and maybe red are a few others that i am aware of. there are probably a few more that are less popular that i don't know.
for me high level implies at least automatic memory management and high level data types.
I mean much of gnome shell is written in JavaScript. But of course GTK is C.
Does Fyne have bindings to other languages? A search for fyne python gave some hilarious AI slop from Gemini suggesting pip install fyne, but the fyne python package is something completely different and unrelated. The nice thing about GTK is it can be used from virtually any language (QT a bit less so but still a lot)
No. Fyne does not have any bindings and never will in the official project. The API is designed to work perfectly with the Go idioms and using it from any other language will be no where near as intuitive. Not to mention it would slow down the developers of the toolkit as well!
This takes forever to load.
First of all cool concept. I'm looking forward to playing with the DE even if it doesn't replace my daily DE. In my experience, extending an existing project in Go is much faster than lower level languages. The opinionated build and dependency system can seem limiting but really helps one get up to speed quickly on a new project. Just setting up a build environment for a low level language based project can be enough of a hassle/time sink to dissuade me from attempting with a quick toy project.
> 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.
Your comment seems very entitled.
When it’s ready, and faster if you help.
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!
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.
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.
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.
actually, it's more like you are selling clothes, and i don't like the style, and i am telling you which style i'd like to buy.
you don't have to produce my style, and i don't have to buy your clothes, but it's good to talk about our preferences so you have a better idea of the potential market.
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.
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)
Thanks for chiming in, and the link, now I will have to waste some weekends with Fyne Conf content. :)
Perfect :) there are so many great projects and that conference introduces some excellent looking apps.
> 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.
Thanks for the heads up, have to play around with this.
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.
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.
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.
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.
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.
You can configure branch protections in GitHub to rebase during PR merges and enforce a linear history.
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!
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.
Yes I know. That's not how they said they are doing it.
Sorry but you building wrong if you need separate builds.
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.
> 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).
> 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.
> 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?
Before git abused the terminology, a branch used to refer to a long-lived/persistent commit lineage, most often implemented as a commit-level flag/attribute,
OTOH, git branches are pointers to one single commit (with the git UI tentatively converting this information sometimes into "that commit, specifically" or sometimes as "all ancestors commits leading to that commit", with more or less success and consistency).
Where it matters (besides fostering good/consistent UX) is when you merge several (topological) branches together: git won't be able to tell if you just merged A into B or B into A. Although the content is identical at code-level, the semantic/intent of the merge is lost. Similarly, once the head has progressed so much ahead and your history is riddled with merges, you can't tell from the DAG where the individual features/PR/series start and end. This makes bisecting very hard: while hunting down a regression, you would rather avoid checking-out mid-series commits that might break the build, and instead stick to the series boundaries. You can't do that natively with git. That also makes maintaining concurrent versions unnecessarily difficult, and many projects are struggling with that: have you seen for instance Django¹ prefixing each and every commit with the (long-lived) branch name? That's what you get with git while most other VCSes (like Mercurial, my preference) got right from the start.
¹: https://github.com/django/django/commits/stable/6.0.x
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
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.
see my sibling comment here: https://news.ycombinator.com/item?id=45479690
tl;dr you lose some semantic (and practical capabilities, UX and effectiveness) when you don't capture branch information at commit-level
> 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.
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...
> 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.
> But isn't "multiple release versions of an app" just "one application, with multiple different configurations"?
That would be nice (and evergreen), but that's not always the case. It's common to have different versions of the app released simultaneously, with different features and bugfixes shipped.
Think of Microsoft simultaneously supporting Windows 10 and 11, while still releasing patches for XP: they are all individual OSes that share some common code, but can't be detangled at build times[1]
The customer will be reluctant to upgrade major versions due to licensing costs and risk if breakage (your code, or their integrations), but still expect bugfixes (and only bugfixes) on their deployed versions, which you're contracted to provide. Using the evergreen approach.
I'm not convinced using build flags to manage which code is shipped is superior to release branches, I fall on the side of release branches because using bisect is invaluable.
1. I suppose as long as the build system is turing complete, one could hypothetically build Windows XP, 7, 8, 10 and 11 off the same codebase using flags. I would not envy that person.
"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.
> 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
Generally agree. All changes for me are cherry-picked to master only.
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…
That's hilarious. I'd be so pissed if I was their manager (or their manager's manager).
Brainless politics ruined coding
usual passive-aggressive HN comment on someone's effort
This actually looks quite good for a brand new development. I am big fan of vertical docks but that vertical time...
Last update to master was last year, develop not much more going on. It looks like it was started 7 years 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.
Master isn't the development branch though; you want these things to be fairly stable.
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.
New? It doesn't even look like it supports Wayland.
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?
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.
Wayland is a must for me at this point. If it starts supporting it I will give it a serious try
You can expect work to begin on that after the upcoming major release. We are waiting on a fix in an upstream library.
Honest question: why? I tried Wayland for a while but couldn’t tell what is different about it as just a user.
Not OP but seamless (tearfree) rendering and fractional scaling for displays are the two big goodies, for me.
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.
Search for Wayland I think the debate is not new.
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.
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
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!
Just FYI, there's only two members who are visible if you're not in the organization yourself.
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 :).
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?
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 ;).
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.
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 :).
Are you guys on IRC or Discord or anything?
Sure thing, we hang out on the Fyne Discord server https://discord.gg/uWPJpkKcR
Perfect! I'll be sure to pop in later today, I'm on Arch Linux, currently using Wayland, so this will be interesting!
What does this do (or will it do) better than existing DE's?
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.
Will definitely give it a shot this weekend. Any known quirks to be aware of on Pop!_OS 22?
Neat. I wonder what performance is like compared to normal desktop environments.
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.
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.
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.
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…
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.
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.
The Project Looking Glass UI came to iPadOS and MacOS via Stage Manager https://support.apple.com/en-gb/guide/mac-help/mchl534ba392/...
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.
> 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
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.
> [...] that Apple would sue Sun if they moved forward to commercialize it – Jobs felt the project infringed Apple's intellectual property.
Classic Apple.
Jobs dropped such suggestions after he was informed Keynote would get hit back
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.
> 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.
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.
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?
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.)
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.
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.
That doesn't require multi threading.
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.
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
Depends on how much Electron crap is running alongside the desktop.
“Don’t you guys have fast computers?”
My computers are old and slow.
They run XFCE just fine.
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
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.
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.
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.
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...
I'm looking forward to the v2.7.0 - I think this will fix the glacial scrolling on Android which is great!
I bet running circles around the JavaScript mess of GNOME.
Previous discussion: https://news.ycombinator.com/item?id=40011100 (2024, 64 comments)
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
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!)
X or Wayland?
It seems to rely on compton so no Wayland I guess, which makes is an interesting toy, but not a serious option.
Latest commits on develop replace Compton with a builtin compositor.
Ready for a wayland support to begin after the next release!
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?
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...
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.
I see, that's good.
You like fyne a lot, huh? I started writing a desktop app with it but got stuck, it can't really do very nice tables and the styling is not flexible enough for me
Looks promising. Will try this weekend. Any tips to quickly try it out?
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.
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!
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 :).
god i would love a sensible windows 2000 or macos 10.6 desktop right now
Nice werk
> FyneDesk: A full desktop environment for Linux written in Go
Monocrome icons, tiny scrollbars, label buttons, Material design at its finest. Nothing new here. /s
[flagged]
So true, 3 days without commits is too much.
Perhaps you could use some tips on using GitHub.
who is "we" and are you part of "them" ?