41–50 of 65 posts
Unpopular opinion: Ditch everything GNOME, glib, vala, GTK and focus on making KDE, Qt, QML first class software. QML is powerful and is quite fast and can at least be made fast. KDE needs UI and design polish but the foundations are IMHO more sane than GNOME ever was. Move the good stuff from GNOME over to KDE. E.g. kio-slaves and gvfs should be one stable solid pluggable piece of software. And document that well -…
Sorry, but I believe this effort is doomed to fail if you don’t provide compatibility with the open web. It is the only online app distribution environment that has really thrived, other than Apple’s and Google’s. Of course you could do this easily with electron apps. Too much bloat? Fine- go with a ReactNative/NativeScript approach with a JS VM controlling native UI. Hate JS? Fine- compile to it from your language o…
Unpopular opinion: Ditch everything GNOME, glib, vala, GTK and focus on making KDE, Qt, QML first class software. QML is powerful and is quite fast and can at least be made fast. KDE needs UI and design polish but the foundations are IMHO more sane than GNOME ever was. Move the good stuff from GNOME over to KDE. E.g. kio-slaves and gvfs should be one stable solid pluggable piece of software. And document that well -…
Qml is an awful xml+javascript layer on top of qt that adds nothing but unnecessary complication to building UI's. Using Qt directly is much simpler.
> QtCreator is usable
Funny, last time I tried it was literally unusable. The new project dialog expanded beyond the height of the screen and all I could do was kill the process.
I was rolling my eyes reading this and then hit this, which is the real value of the article IMO: > few Linux platforms (if any?) had taken a series whack at building a consumer grade app and developer experience. We tried, it was not successful, and instead of digging up the past I would rather ensure we can inform the future. "What not to do, and how not to do it" are at least one valid take away from that whole er…
One of the big issues with their attempt was ~0 support or documentation for porting existing applications. Everything was focused around building an Ubuntu app from scratch using their custom qtquick-based SDK, but that's not what we needed. edit: for more info: This guy made a beautiful summary of the issues with the dev experience around Ubuntu (Touch): http://www.lieberbiber.de/2017/06/20/my-ubuntu-for-mobile-de.…
Sorry, but I believe this effort is doomed to fail if you don’t provide compatibility with the open web. It is the only online app distribution environment that has really thrived, other than Apple’s and Google’s. Of course you could do this easily with electron apps. Too much bloat? Fine- go with a ReactNative/NativeScript approach with a JS VM controlling native UI. Hate JS? Fine- compile to it from your language o…
The big problem with web apps as first-class citizens is UI inconsistency. What I love about native desktop apps is that they should all follow well-defined user interface guidelines and all use the same toolkit/theme. With web apps, you don't get that - every web app uses its own fonts, its own styles, its own UI structure and navigation.
[1] Except apps written by the OS developer.
Correct me if I am wrong but wouldn't the best move forward just be supporting and tuning https://electron.atom.io to make it more performant and supported on linux? Yes it is a battery killer, but I can see it being better if everyone put their tasks to making that a non issue. edit: why the down votes? This is a platform agnostic framework. I understand the performance is bad, but the one reason that linux doesn't…
Earlier quoted context omitted.
Bad for battery and ram. Fixing this is probably difficult to impossible. I have 10 apps open imagine if they were all using 1-2GB of ram.
The issue is that electron is running a new chromium process for each application. This could be fixed easily sharing that process and making chromium more resource friendly.
Earlier quoted context omitted.
Browser-based apps still kinda suck. Battery-wise, UI-wise in terms of integration, accessibility-wise, etc. And they're a huge step down in programming language availability vs native apps.
Most languages have the option to compiling to JS, all I am suggesting is that electron be the framework that people target. Having language support is possible by extending that framework.
Unpopular opinion: Ditch everything GNOME, glib, vala, GTK and focus on making KDE, Qt, QML first class software. QML is powerful and is quite fast and can at least be made fast. KDE needs UI and design polish but the foundations are IMHO more sane than GNOME ever was. Move the good stuff from GNOME over to KDE. E.g. kio-slaves and gvfs should be one stable solid pluggable piece of software. And document that well -…
Earlier quoted context omitted.
One of the big issues with their attempt was ~0 support or documentation for porting existing applications. Everything was focused around building an Ubuntu app from scratch using their custom qtquick-based SDK, but that's not what we needed. edit: for more info: This guy made a beautiful summary of the issues with the dev experience around Ubuntu (Touch): http://www.lieberbiber.de/2017/06/20/my-ubuntu-for-mobile-de.…
Since this thread is about the desktop, don't existing GNOME apps just work under Unity Desktop?
A few points of division are pulseaudio and wayland. Pretty much everybody now uses pulse and while most apps will work in wayland I don't know of any that require it yet.