[HN Gopher] FyneDesk: A full desktop environment for Linux writt...
___________________________________________________________________
FyneDesk: A full desktop environment for Linux written in Go
Author : xk3
Score : 244 points
Date : 2025-10-03 02:13 UTC (20 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| koeng wrote:
| Neat. I wonder what performance is like compared to normal
| desktop environments.
| gigatexal wrote:
| 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.
| munchlax wrote:
| 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?
| gigatexal wrote:
| 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
| shmerl wrote:
| 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 wrote:
| That doesn't require multi threading.
| shmerl wrote:
| 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.
| nasretdinov wrote:
| 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
| wiseowise wrote:
| "Don't you guys have fast computers?"
| munchlax wrote:
| My computers are old and slow.
|
| They run XFCE just fine.
| Twirrim wrote:
| 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 wrote:
| Depends on how much Electron crap is running alongside the
| desktop.
| robinsonb5 wrote:
| 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.)
| matttproud wrote:
| 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.
| radicaldreamer wrote:
| The Project Looking Glass UI came to iPadOS and MacOS via
| Stage Manager https://support.apple.com/en-gb/guide/mac-
| help/mchl534ba392/...
| ffsm8 wrote:
| 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.
| bestham wrote:
| 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.
| heavyset_go wrote:
| > _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
| blauditore wrote:
| > [...] 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 wrote:
| Jobs dropped such suggestions after he was informed
| Keynote would get hit back
| andydotxyz wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pjmlp wrote:
| 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.
| SkiFire13 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| ikiris wrote:
| 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 wrote:
| 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 wrote:
| I'm looking forward to the v2.7.0 - I think this will fix
| the glacial scrolling on Android which is great!
| ikiris wrote:
| 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 wrote:
| 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...
| pjmlp wrote:
| I bet running circles around the JavaScript mess of GNOME.
| cfn wrote:
| This actually looks quite good for a brand new development. I am
| big fan of vertical docks but that vertical time...
| sgc wrote:
| Last update to master was last year, develop not much more
| going on. It looks like it was started 7 years ago.
| andydotxyz wrote:
| 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_ wrote:
| Master isn't the development branch though; you want these
| things to be fairly stable.
| sgc wrote:
| 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 wrote:
| New? It doesn't even look like it supports Wayland.
| kristianp wrote:
| 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 wrote:
| 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.
| repeekad wrote:
| 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 wrote:
| That's hilarious. I'd be so pissed if I was their manager
| (or their manager's manager).
| DagsEoress wrote:
| Brainless politics ruined coding
| gouggoug wrote:
| 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 wrote:
| 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 wrote:
| 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.
| brabel wrote:
| 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!
| jiggunjer wrote:
| Sorry but you building wrong if you need separate builds.
| skydhash wrote:
| 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.
| tankenmate wrote:
| 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 wrote:
| Yes I know. That's not how they said they are doing it.
| jmmv wrote:
| You can configure branch protections in GitHub to rebase
| during PR merges and enforce a linear history.
| ezst wrote:
| > 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).
| zx8080 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| gouggoug wrote:
| > 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.
| kardianos wrote:
| Generally agree. All changes for me are cherry-picked to
| master only.
| j1elo wrote:
| "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 wrote:
| > 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
| overfeed wrote:
| > 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 wrote:
| 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/customiz
| ing...
| gouggoug wrote:
| > 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.
| gjvc wrote:
| usual passive-aggressive HN comment on someone's effort
| sam_lowry_ wrote:
| X or Wayland?
| shmerl wrote:
| It seems to rely on compton so no Wayland I guess, which makes
| is an interesting toy, but not a serious option.
| em-bee wrote:
| 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?
| shmerl wrote:
| I see, that's good.
| andydotxyz wrote:
| 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/fynede
| s...
| em-bee wrote:
| 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.
| andydotxyz wrote:
| Latest commits on develop replace Compton with a builtin
| compositor.
|
| Ready for a wayland support to begin after the next release!
| pjmlp wrote:
| 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 wrote:
| 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 wrote:
| Thanks for chiming in, and the link, now I will have to waste
| some weekends with Fyne Conf content. :)
| andydotxyz wrote:
| Perfect :) there are so many great projects and that
| conference introduces some excellent looking apps.
| Rochus wrote:
| > _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 wrote:
| Thanks for the heads up, have to play around with this.
| pablo1 wrote:
| Wayland is a must for me at this point. If it starts supporting
| it I will give it a serious try
| andydotxyz wrote:
| You can expect work to begin on that after the upcoming major
| release. We are waiting on a fix in an upstream library.
| brabel wrote:
| Honest question: why? I tried Wayland for a while but couldn't
| tell what is different about it as just a user.
| pacifika wrote:
| Search for Wayland I think the debate is not new.
| gorgoiler wrote:
| Not OP but seamless (tearfree) rendering and fractional
| scaling for displays are the two big goodies, for me.
| andydotxyz wrote:
| 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.
| rudderdev wrote:
| Looks promising. Will try this weekend. Any tips to quickly try
| it out?
| andydotxyz wrote:
| 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.
| omgmajk wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=40011100 (2024, 64 comments)
| jjoe wrote:
| Will definitely give it a shot this weekend. Any known quirks to
| be aware of on Pop!_OS 22?
| robert-zaremba wrote:
| 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
| hsbauauvhabzb wrote:
| Your comment seems very entitled.
|
| When it's ready, and faster if you help.
| SpaceNugget wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| hu3 wrote:
| > 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 wrote:
| I was under the impression that there's a seamless
| compatibility layer for running X11 under Wayland?
| dijit wrote:
| Xwayland exists, but you need a compositor to be running to
| encapsulate the Xwayland container.
| eadmund wrote:
| 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.
| andydotxyz wrote:
| 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.
| aboardRat4 wrote:
| 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 wrote:
| 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/)
| LollipopYakuza wrote:
| 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 wrote:
| 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 wrote:
| This takes forever to load.
| antonvs wrote:
| > 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.
| hyperbolablabla wrote:
| 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
| ingen0s wrote:
| Nice werk
| jamesnorden wrote:
| 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.
| gjvc wrote:
| god i would love a sensible windows 2000 or macos 10.6 desktop
| right now
| giancarlostoro wrote:
| 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 wrote:
| 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 :).
| giancarlostoro wrote:
| Are you guys on IRC or Discord or anything?
| andydotxyz wrote:
| Sure thing, we hang out on the Fyne Discord server
| https://discord.gg/uWPJpkKcR
| giancarlostoro wrote:
| Perfect! I'll be sure to pop in later today, I'm on Arch
| Linux, currently using Wayland, so this will be
| interesting!
| danielspace23 wrote:
| 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 wrote:
| 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 :).
| gwbas1c wrote:
| 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 wrote:
| 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 wrote:
| Just FYI, there's only two members who are visible if you're
| not in the organization yourself.
| andydotxyz wrote:
| 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 wrote:
| 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 wrote:
| 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 ;).
| bogwog wrote:
| 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!
| andydotxyz wrote:
| Amazing comment and thanks for the support!
| entropie wrote:
| > that doesn't support Wayland
|
| Dont know what the state is but they work on it
|
| https://github.com/FyshOS/fynedesk/issues/76
| AlienRobot wrote:
| What does this do (or will it do) better than existing DE's?
| andydotxyz wrote:
| 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.
| laurent_du wrote:
| 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 wrote:
| 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.
| oflebbe wrote:
| 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 wrote:
| 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!)
___________________________________________________________________
(page generated 2025-10-03 23:01 UTC)