[HN Gopher] Pangolin UI, a Desktop Shell, Written in Flutter, fo...
___________________________________________________________________
Pangolin UI, a Desktop Shell, Written in Flutter, for Linux and
Zircona
Author : denysvitali
Score : 144 points
Date : 2021-04-17 09:26 UTC (13 hours ago)
(HTM) web link (web.dahliaos.io)
(TXT) w3m dump (web.dahliaos.io)
| agloeregrets wrote:
| It's a pixel perfect copy of ChromeOS? Really it is.
| yegle wrote:
| I tried it on Pixel4XL and the performance is definitely not
| 60fps but acceptable. Moving window around seems smooth to me.
| flohofwoe wrote:
| Hmm... on my mid-2014 13" MBP (which is completely fine
| otherwise) performance is so bad that this doesn't really make me
| confident that Flutter is "the future". Even just dragging
| windows around stutters (it feels like somewhere between 5 and 10
| FPS). Is "native performance" comparable to the web version or
| dramatically better?
|
| Flutter... stutter... maybe the Flutter team was trying to tell
| us something all along ;)
| dmos62 wrote:
| I really wish app developers would throttle their prototypes.
| They tend to run overpowered machines, but then they're
| oblivious to performance problems their apps have. As a
| consequence, users have to keep playing catchup with
| developers' computers. I feel strongly about this. I can't say
| with a straight face that the growth in apps' resource
| consumption over the last ten years reflects in improvements in
| their feature-set. Feels a bit like how gold fish get big if
| you put them in big aquariums.
| mimixco wrote:
| Software will always outrun hardware, and ginormous software
| drives the entire existence of the hardware business. It's
| just how the system works. Are we getting benefits? I can
| think of lots of software we didn't have 10 years ago that we
| wouldn't want to give up just so we could keep old, slow
| boxes.
| dan-robertson wrote:
| If you want to work on something like flutter, which will be
| optimised for the hardware of the day when it is done, and
| therefore the hardware of the future when it is being
| developed, then surely it makes sense to start with a
| prediction of how future hardware will be (eg gpu more
| important, possibly more pixels to push, more (not faster)
| processor cores, possibly higher framerates), and then try to
| approximate that with a powerful present-day computer.
|
| Though in this case it feels like problems might be due to
| running in a web browser and not being optimised.
| vendiddy wrote:
| Any guides or tools for doing this? Some devs on our teams
| now now have M1s. I worry they won't feel the pain of slow
| apps if they develop with such fast computers. Meanwhile
| we've got a number of customers who use computers that are 5+
| years old.
| calvinmorrison wrote:
| Buy old laptops and routinely test on them. We keep a lot
| of old devices around solely as test devices
| dmos62 wrote:
| I don't have experience doing this, but I'd experiment with
| VMs and their performance settings. It would be a pretty
| ergonomic solution. Rpi or some x86 single board computer
| might make sense too. I guess what's viable depends on the
| stack and the software itself.
| EvilEy3 wrote:
| It's not about throttle. It is incapable to run faster at the
| moment.
| RedShift1 wrote:
| This 100x. I've always said, developers should get a Pentium
| 3 500 MHz and 128 MB of RAM to test their software. And yes I
| am following my own advise, I use an old Dell with a Core 2
| Duo T8100 and 2 GB of RAM to test my software on (oldest I
| could find at work).
| anthk wrote:
| Today I'd choose a Pentium 4/Athlon with SSE2 and 512MB of
| RAM as the minimum.
| throwaway894345 wrote:
| I don't think it's developers' devices that are driving the
| trend as much as economics. Resources get cheaper so people
| get faster computers and developers can release faster by
| forgoing optimizations all while delivering the same levels
| of performance. Of course, this excludes potential customers
| who can't afford to update, but those are probably not the
| folks off of whom app devs are making their money. Of course,
| this doesn't legitimize the decision to forego optimizations
| --I'm only noting that it's probably not the performance of
| developer machines in particular.
| dmos62 wrote:
| I've considered that, but I don't have the impression that
| app development has gotten faster over the last decade. I
| bet there's people who can chime in here.
| throwaway894345 wrote:
| If we're not spending the time optimizing, it must be
| going somewhere. If it's not going into faster, more
| frequent releases it might be going into improved quality
| (though I doubt that as well, from experience) or perhaps
| even just employing cheaper developers (and QA and
| management and design and etc) such that they produce
| software of the same performance in the same amount of
| time.
| kodah wrote:
| It certainly has. Frameworks like Rails or Django didn't
| exist, pre-built component libraries weren't even a dream
| yet, and everyone was trying to get software to run
| consistently on each other's machines.
|
| These days there's worlds of abstraction between you and
| those problems. Those abstractions are in transpilation,
| libraries, etc which all take more power to get over the
| problem of time.
| regularfry wrote:
| >> last decade
|
| > Frameworks like Rails or Django didn't exist
|
| You... might want to check the git histories. And a
| calendar.
| andrepd wrote:
| Oh absolutely. And internet speed as well.
|
| Have them use their shitty 5MB webpage over a spotty 500kbps
| on a phone with 1GB RAM. Maybe they'll see what it feels like
| to have the page load bit by bit over a minute with stuff
| jumping around all the time. Maybe they'll reconsider if they
| need 5 megs of js to display text and images then.
| 0-_-0 wrote:
| Do you have HW acceleration enabled in your browser? It makes a
| huge difference.
| t8y wrote:
| I think this is using the HTML renderer. On any other platform
| it would be using Skia and should be faster. The author could
| compile the app using Skia on WebGL potentially giving a speed
| boost.
| jeroenhd wrote:
| My experience with Flutter has been a lot better than what this
| website demonstrates. I'm not sure how much of the stutter is
| to be blamed on Flutter and how much is to be blamed on the
| code architecture of this website.
|
| This website is definitely running at 20-30fps max on my phone,
| whereas 60fps seems perfectly maintainable on my own Flutter
| experiments with web apps.
|
| Having said all that, I'm still miffed about the extreme
| reliance on Javascript modern web applications have. With the
| ease of use Flutter promises for making web apps, I can only
| fear the slow, janky mess that websites will become if the
| platform ever gets taken up as quick as Flutter seems to hope
| it will.
| tenaciousDaniel wrote:
| There are at least two projects I know of that are using WASM
| to implement web applications without JavaScript. Personally
| I think that's the future:
|
| https://vugu.org
|
| https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
| dathinab wrote:
| The problem is flutter (web) also doesn't use html/css...
| tenaciousDaniel wrote:
| They re-implement everything in canvas I assume? If so,
| wow, that's pretty awful.
| dvdkon wrote:
| Why? At this point, the browser is mostly an app runtime,
| so I don't think avoiding HTML and CSS is necessarily a
| bad thing. With some tuning it could even be faster,
| although I don't think any project has gotten to that
| point yet.
| tenaciousDaniel wrote:
| Because of the sheer amount of effort that browsers have
| put into solving all sorts of tricky problems, such as
| internationalization and accessibility. Once you try to
| render your own text inputs, you're committing to
| replicating a mountain of functionality. HTML is
| deceptively simple.
| vbsteven wrote:
| HTML, the dom, css and JS in browsers are far from
| simple. IMHO we've been tacking on more and more
| "application stuff" on top of a document viewer since the
| mid 90s. The whole reason React and other virtual dom
| frameworks exist is to wrangle the original document
| viewer into an application platform.
|
| Yes, after all those years browsers are top notch when it
| comes to accessibility, but it comes with lots of
| additional complexity.
|
| I am hopeful that with things like WASM and Canvas we are
| finally starting to move away from this document-based
| paradigm towards more app-focused paradigms.
|
| Although there is still lots of work to be done to make
| approaches like this work with accessibility tools.
|
| Sometimes i think that we are deliberately not adding dom
| support to wasm in order to not make the same mistakes we
| did when trying to make html/css/js suitable for apps.
| dathinab wrote:
| I can understand you, but IMHO for most websites a
| document focused paradigm is just the right fit.
|
| I mean e.g. a news site is just a collection of documents
| in the end, blogs are just documents, so is wikipedia.
| Search machines are basically like external indices,
| which fit well as documents and even things like booking
| sites are in the end just fancy formulars.
|
| Sure there are a lot of more "app" like usage, and for
| them having a different base is very important.
|
| But I'm not the biggest fan of "turning" document use
| cases into apps (as many sites already try to do today),
| as this in my experience adds a lot of overhead and
| includes a massive bucket of behavioral differences which
| can make it very hard for some people to use the
| internet.
|
| If everyone would agree of how roughly apps should behave
| for the roughly same UX aspect it would be fine. But
| people don't I mean look at the massive UX divergence
| which slowly creeped in between Android(Stock) and iOs.
| Worst this is a very subtitle creep at many places and it
| often seems as many designer doesn't realize that what
| they think is innovative (and might be innovative for
| e.g. a iOs) user isn't necessarily innovative for a lot
| of other people (e.g. all the Android users). Or in other
| words the whole concept of what is innovative diverged
| between different grubs of people even if they belong in
| the same "culture"/country/etc..
|
| Anyway still for the places where it does make sense
| having a alternative to HTML/CSS is nice but I believe it
| must be browser native, non vendor specific, standardized
| and have first class accessibility support.
|
| Non of which applies to Flutter (web) in the way it
| currently is.
| vbsteven wrote:
| Yes, we definitely want similar things. Maybe it was not
| clear from my original reply but I'm not saying the
| document paradigm is bad and we should move away from it.
|
| The document paradigm has evolved for 25 years and it is
| the right fit for most "websites".
|
| The problem is that we're trying to build apps on the
| same base as well and that is where the mismatch is.
|
| If you look at cross platform GUI toolkits like Gtk, Qt,
| Flutter and Druid, what most of them have in common is
| that they are typically abstractions on top of a graphics
| rendering library (cairo, skia, canvas) with integration
| into platform accessibility and window APIs.
|
| That makes them easily portable to Linux, Windows,
| Android, iOS etc.
|
| The problem with the web browser as a target platform for
| these toolkits is that the accessibility support is
| currently coupled too tightly with dom/html/css.
|
| The graphics drawing toolkit is there (canvas) and most
| of the above toolkits have abstracted over it already.
| The missing link is standardised accessibility APIs in
| browsers that can be used with canvas instead of dom.
| tenaciousDaniel wrote:
| That framing makes sense. I've always thought the
| document model was poorly suited for modern applications.
| I'm still not sold on canvas itself being the solution -
| I'd rather open up the underlying accessibility/i18n tech
| so that developers don't have to reinvent the wheel. But
| yes, otherwise agree with you.
| vbsteven wrote:
| My ideal solution would be that we can add accessibility
| apis to canvas. That means we can write GUI toolkits in
| any language compiling to wasm using canvas apis. Those
| toolkits gain accessibility support through canvas.
|
| edit: some toolkits already have wasm/canvas support
| (like Flutter and Gtk I think). The missing link is the
| ability to integrate accessibility.
| dathinab wrote:
| Not just that. There is quite a bunch of thinks you
| simple can't do (in reasonable high quality) with canvas
| rendering without it undermining the users privacy.
|
| E.g. you can do _a lot_ to reduce the fingerprint-ability
| of canvas (Google doesn 't care) but doing so will lead
| to potentially slightly slower rendering and in turn
| potentially less fluid animations.
|
| You can't have links as in a website without getting
| access the the whole browser history.
|
| You can't take advantage of the GPU in the same way the
| browsers can.
|
| You always have quite a bit of size and (potentially)
| load time overhead (I mean just look a Pangolin UI for a
| good example for this).
|
| And "everyone" potentially ships their own copy of a
| whole UI framework (not just some layers on top of it
| like it's common in the web). So if there is a rendering
| but normally it get's fixed by you browser but now it
| needs to be fixed by library authors and then the fix
| needs to be used by the website which had a problem.
|
| I think a non document based base would be nice, but it
| needs to be browser native, standardized, not vendor
| specific and with first class accessibility. At least at
| the core. And let's be honest flutter is non of this. And
| given some decisions like making text non selecteable by
| default I don't see it ever coming to that point tbh.
| dvdkon wrote:
| Yes, it's a lot of work to create a good GUI toolkit. But
| it's not impossible either, and Flutter developers have
| already put in a lot of work into getting things just
| right on mobile, so I think they have a good shot at
| doing the same on the web.
| EvilEy3 wrote:
| > just right on mobile
|
| If by "just right" you mean sticking out like a sore
| thumb on iOS, then sure.
| miohtama wrote:
| It is impossible because on web you do not get access to
| low level UI primitives like input controls as you would
| on mobile. They cannot e.g. read clipboad, access native
| context sentive menus and such.
|
| Flutter on web can do Flash applications of 2020, but for
| most web use cases it is not possible to "get it right".
| dvdkon wrote:
| I don't think Flutter uses native UI primitives anywhere,
| but you're right that web APIs have been designed for
| HTML documents/apps and will need modification for non-
| HTML apps. We aren't there yet, but I'm convinced we'll
| get there at some point.
| ridethebike wrote:
| Flash and Silverlight were unavailable to comment
| EvilEy3 wrote:
| Good luck with accessibility and compatibility with
| browser plugins.
| dathinab wrote:
| The main reason: Accessibility in _many_ variants.
|
| E.g. I need to change font's/font colors/background
| colors from time to time because they are extremely
| exhausting for me to read, I can't do so with Flutter.
|
| Screen readers know how to process HTML, CSS. But how are
| they supposed to know what some "arbitrary" painted pixel
| are supposed to mean. And yes they already have to do a
| awful amount of trick due to people incorrectly (one
| higher semantic level) use HTML & CSS.
|
| Many of the defaults of Flutter (Web) are horrible, at
| least the last time I checked. E.g. text is unselectable
| by default instead of it being an opt in some site which
| have problems with stolen text content have use (and you
| still can steal it anyway just screenshot + OCR, duh).
|
| Lastly (some) browsers optimized for good (e.g. fast or
| battery friendly) HTML/CSS rendering, non of this applies
| to Flutter. E.g. Firefox has a pretty need
| parallelization of layout and rendering allowing quite
| awesome usages of CSS animations, non of this will ever
| be possible in Flutter without replacing DOM with Flutter
| natively, at which point we have then a Google web
| instead of an internet. (Through tbh. replacing HTML+CSS
| with some proper abstracted API of flutters inner
| workings is tempting, it has some quite need aspects,
| that is if Accessibility works by then.)
| dvdkon wrote:
| A lot of work has been put into accessibility on the web,
| and the "semantic HTML" document model that works so
| poorly for apps helped too. There's no reason
| accessibility needs to be bad for anything non-HTML, at
| least not with supporting screen readers.
|
| I also think text not being selectable by default is an
| OK default _for apps_ (actual desktop-grade apps, not
| websites with interactive elements).
|
| Right now, in 2021, it's probably a bad idea to create a
| web app with Flutter or any other non-DOM-based toolkit,
| but I don't think that will be the case forever. The
| native apps I use are all as good as or even better than
| browsers at being fast and battery-friendly. They might
| achieve that by being more limited and not supporting all
| the features and usecases of HTML5, and that's perfectly
| fine. It's not impossible that we'll see similar high-
| quality GUI frameworks inside browser runtimes.
| domano wrote:
| There are 2 modes you can choose from, one is using html
| but is less performant.
| namuol wrote:
| > I'm still miffed about the extreme reliance on Javascript
| modern web applications have.
|
| Flutter is written in Dart, which needs to compile to JS or
| WASM to run on the web, but can compile to native code. I'm
| guessing the native app is a lot faster.
| jchw wrote:
| I'm confused. It runs smoothly on my iPhone.
| flohofwoe wrote:
| That's not necessarily surprising, unless your iPhone is also
| from 2014 ;)
| nethunters wrote:
| On my mobile dragging windows is smooth. Could be hardware
| acceleration not being enabled or browser specific.
| Shadonototro wrote:
| the problem is not the tech, flutter is perfectly fine
|
| it's the developer that uses the tech, or rather misuses the
| computer
|
| you jump to conclusion rather quickly, that's fishy
| forgotpwd16 wrote:
| >Is "native performance" comparable to the web version or
| dramatically better?
|
| Tried their latest ISO[0] on QEMU and... no, it's mostly the
| same. But based on the release notes VM lag is a known issue.
| Maybe someone can try it baremetal and tell us how it went.
|
| [0]: https://github.com/dahliaOS/releases/releases
| swiley wrote:
| It's probably because they haven't paid attention to software
| rendering. Many people don't seem to appreciate how well most
| popular UI toolkits work if your GPU drivers are incomplete
| or missing. (or if you just don't have hardware that supports
| modern OpenGL APIs.)
|
| This, among other more Googly reasons, is why I'm personally
| not a flutter fan. It's not like there aren't other decent
| cross platform UI toolkits anyway.
| stephc_int13 wrote:
| With the serious slowdown of Moore's law, we should not
| continue to build apps in such a way that they run like a dog
| with one leg.
| tyingq wrote:
| No stutter on Chrome/Windows on an older Dell Laptop. Maybe
| it's not doing well with Webkit?
| flohofwoe wrote:
| It's also on Chrome (for Mac), latest Big Sur Beta. Firefox
| and Safari doesn't work at all (white screen). One reason
| could be overdraw, the Intel GPUs in older MBPs barely have
| enough fillrate to render one layer of pixels on a Retina
| display. E.g. many WebGL demos which render at Retina
| resolution and either use lots of alpha blending or complex
| pixel shaders are also stuttering on this setup.
|
| Still, an UI framework should never eat away so much
| performance. Even at full display refresh rate it should only
| consume a small percentage of available computation power.
| tyingq wrote:
| Ah, so back to the old "runs best on <browser>" approach :)
| tluyben2 wrote:
| On my $200 android phone it is actually rather smooth after the
| initial download to my browser. Surprisingly so. It performs
| more fluent than the most apps on my pinephone and so: are
| there plans to make a native distro? This would make for a nice
| change as wm.
| ilrwbwrkhv wrote:
| yes same... lag feels so bad... reminds me of the slack app...
| at least this one is a whole desktop...
| stephc_int13 wrote:
| Tried it, found it unresponsive, unpleasant first-time user
| experience.
|
| Won't do.
| nitinreddy88 wrote:
| Wait for Google to shelve it in 2021.
| virmundi wrote:
| I'm worried about that. I might be starting a medical
| application. I want a single language to teach to on-devs for
| front end and backend work. Dart looks good however, I don't
| trust Google.
| ohgodplsno wrote:
| Have you considered Jetpack Compose ?
| (https://developer.android.com/jetpack/compose) Despite it
| being a Google project, it also has backing from Jetbrains
| (https://www.jetbrains.com/lp/compose/). Having access to the
| full JVM environment of libraries is an infinitely better
| state than Dart, and Kotlin is also a much more pleasant
| language. Testing cycle is sliiightly slower, but Compose
| previews make it easy.
| arthur_sav wrote:
| I wouldn't be using such experimental technologies for
| anything else than toy projects.
| alskdj21 wrote:
| I've been playing with compose and it looks really good.
| Note that it's still on beta(api should be considered
| stable) with a release this year. Previews are kinda wonky
| for now. Sometimes it wouldn't refresh. How hard is it to
| implement hot reload?
|
| And like I mentioned before, with my low-end laptop its
| hard to run full Android Studio. Tho Dart's not that
| pleasant compared to Kotlin, the tooling outside a single
| IDE was enticing for me.
| nsonha wrote:
| > I want a single language to teach to on-devs for front end
| and backend work
|
| if that's what you want then you should support things like
| kotlin multiplatform, react-native or SwiftUI, dart is a very
| meh language comparing to those above with established back-
| end ecosystems.
| hajile wrote:
| I think you don't need to worry about that. They've probably
| invested around fifteen years of time into the language.
|
| They want it because it gives them control over their future
| in a way that Kotlin or Java and the JVM do not.
|
| The "bundle the whole world in your app" isn't space
| efficient, but it's efficient enough and sidesteps a large
| part of the outdated Android issue. Meanwhile the react-style
| components are very popular among devs with UI know-how. The
| rapid uptake of Flutter also speaks to the hole it is
| filling.
|
| Then there's FuschiaOS where they're seemingly intent on
| making it the primary dev language.
|
| Lots of good reasons to continue support and not many reasons
| not to. Sounds like a decent bet to me
| z5h wrote:
| I get the sentiment. But it seems Google is "all in" on Dart
| and Flutter. https://insights.dice.com/2019/03/27/fall-rise-
| dart-google-j...
| mkl wrote:
| Google was all in on Google+ too. Probably moreso.
| joezydeco wrote:
| Until the next shiny thing. Don't fall for it.
| [deleted]
| muterad_murilax wrote:
| Is "Zircona" a project related to Zircon (the core platform that
| powers the Fuchsia OS) or just a typo?
| denysvitali wrote:
| Just noticed, sorry, definitely a typo
| preommr wrote:
| oof hard to be positive about flutter when this is the result
| considering that...
|
| * There's a massive company like Google behind it
|
| * Google has experience with app dev
|
| * It's been 3+ years
|
| * The project has been hyped up a lot, and has a lot of
| supporters
|
| * has a programming language that basically exists to support
| this one dev kit.
| orangecat wrote:
| Currently Flutter is much more suitable for native mobile and
| desktop than for web. If you have the Flutter dev environment
| installed, you can check out the repo and run it as a desktop
| app for a far better experience. The unpolished web support may
| be doing more harm than good, because people looking at demos
| like this can understandably end up with a negative impression.
| tjpnz wrote:
| Some of these arguments once could've applied to Angular. That
| doesn't inspire confidence.
| forgotpwd16 wrote:
| Looks like the web desktops that used (are?) to be popular about
| a decade ago. Otherwise no information is provided or can be
| found. How does one run this on Linux or Fuchsia? Is this open
| source or proprietary? Maybe another link should be used instead.
|
| Edit: Submitter shared the repo link in another comment:
| https://github.com/dahliaOS/pangolin_desktop
| marczellm wrote:
| Doesn't seem to work on Firefox. I get an empty white page.
| flohofwoe wrote:
| Same on macOS Safari.
| samat wrote:
| works on latest stable safari on big sur arm
| read_if_gay_ wrote:
| Same on iOS which is maybe not a surprise?
| mysterydip wrote:
| If you wait a minute stuff comes up on iOS, at least for
| me. Could use some kind of progress bar or other indication
| it's loading.
| read_if_gay_ wrote:
| Ah, thanks for that. So it was just my ADHD kicking in I
| guess.
| adrift wrote:
| Works on mine.
| NullPrefix wrote:
| Have you tried enabling JavaScript?
| MayeulC wrote:
| WFM on Firefox 87 on Linux
| oftenwrong wrote:
| You probably just need to wait for it to load.
| xg15 wrote:
| > _Pangolin UI_
|
| Tagline: "So good, it'll go viral"?
| paultopia wrote:
| RIGHT? Too soon, y'all. Too soon.
| soperj wrote:
| They think that the intermediate animal might be mink now.
| Atomskun wrote:
| Reminds me of something we had more than 10 years ago.
|
| https://en.wikipedia.org/wiki/EyeOS
|
| It certainly ran better than this.
| arzel wrote:
| Extremely smooth on Mac M1. Very cool.
| hadrien01 wrote:
| What are we looking at? All I see is a reproduction of an OS with
| abysmal performance, where everything is fake: the text editor is
| fake, the terminal is fake, the web browser is fake. The only
| thing working is the clock...
| einpoklum wrote:
| Well, it's a mock-up, isn't it?
|
| (If not, then ouch...)
| NullPrefix wrote:
| Calculator looks real to me. Unwieldy and ugly, but still real.
| cmrdporcupine wrote:
| Nope, you can enter numbers but the operations don't do
| anything :-)
| diegocg wrote:
| But it uses $TRENDY_FRAMEWORK!
| ChrisArchitect wrote:
| not new, comments and discussion from 6 months ago:
|
| https://news.ycombinator.com/item?id=24976732
| anthk wrote:
| Google, please, leave the Flutter back and create a GUI for GO
| based on Inferno or an enhanced (dumbed down for the causal user)
| Plan9 UI with pulldown menus for the user, micking allegro or XAW
| and a simple file dialog a la TK.
| pjmlp wrote:
| Inferno used Tk, not really what I would like to see on modern
| computers.
|
| http://www.vitanuova.com/inferno/screenshots.html
| anthk wrote:
| That's just a matter of style. Android could have native
| widgets, and desktops another exact set. Instead of a
| hamburger menu, an automatic horizontal one. And so on.
| pjmlp wrote:
| I used Tcl/Tk in 2000, just re-styling isn't enough for a
| 2021 GUI toolkit.
| anthk wrote:
| I used that too, but Google could adapt Inferno for
| modern standards. No, not material, that's atrocious. At
| least for a desktop.
| GekkePrutser wrote:
| It looks way too "Google" to me :( All the material design and
| flatness, the iconset, it's basically Android in terms of design
| language.
|
| I wouldn't want my Linux distro looking like something from
| Google tbh :)
| malkia wrote:
| I just inspected the page, and saw that this version does not use
| canvas (e.g. "canvaskit") but <flt-xxx> elements - e.g. the HTML
| flutter web output. This may or may not make things slower.
| dathinab wrote:
| White Page without content for me.
|
| Please don't use flutter web, it's a unacceptable accessibility
| nightmare.
| still_grokking wrote:
| It "worked" for me on FF 87 on Linux.
|
| But that's not even a click-dummy "desktop". Also, form the
| tech perspective, it seems pre-alpha state. At least the web
| version renders with maybe 10 fps on a pretty decent machine,
| and every click has at minimum half a second latency. No clue
| why someone put up a website marketing this thing to end-users.
| It looks like 3 to 6 years of hard work form usable, imho.
| g051051 wrote:
| It takes a while to load and display, possibly being hugged to
| death. Leave the tab open for a few minutes and check back in a
| bit.
| MaxBarraclough wrote:
| > White Page without content for me.
|
| Same here. I'm using Firefox.
| ognarb wrote:
| Same here but it work on firefox for Android.
| XorNot wrote:
| Urgh, I don't get having start-menu like buttons which pop up a
| fullscreen display on non-phone format devices.
| zeandcode wrote:
| Really no comment at all?
| denysvitali wrote:
| Sorry, here is the repository. I just found the project and it
| seems really interesting:
| https://github.com/dahliaOS/pangolin_desktop
|
| Their OS, dahliaOS is using it: https://dahliaos.io/
|
| Honestly, never tried it myself, but it definitely looks cool
| and I wanted to share the web version ;)
| onli wrote:
| Something is wrong with the web version and also with the
| website https://dahliaos.io/, links don't open. JS sites that
| don't work in Firefox, right? That's not a great start.
|
| It does look interesting though. It's an UI for Fuchsia or
| Linux, with containers for the other system?
| Ygg2 wrote:
| I opened it on Firefox Android, so maybe it's something
| else?
|
| Edit: It doesn't seem to work really good, but it kinda
| works.
| theginger wrote:
| To be honest i don't know what i am looking at, it looks like
| it might be something fairly impressive but sort of could do
| with a link to a page explaining what it is rather than
| straight to it
| denysvitali wrote:
| Please see my comment bellow: here is the link to the project
| https://github.com/dahliaOS/pangolin_desktop :)
| still_grokking wrote:
| Just an imho related post form the front page right now:
|
| https://news.ycombinator.com/item?id=26845037
|
| How smooth that is compared to this here...
| amelius wrote:
| Is there a way to test the Linux version of this (since the title
| says Linux)?
| [deleted]
| pabe wrote:
| It looks just like a GUI demo but from the information in the
| repo there seems to be more behind it? Is this a real GUI for a
| real OS?
| denysvitali wrote:
| Exactly, check out the project at
| https://github.com/dahliaOS/pangolin_desktop
___________________________________________________________________
(page generated 2021-04-17 23:03 UTC)