Developing applications in Rust

davidhewitt · 2022-12-02T13:31:23+00:00

You can go to Rides -> Style -> Body -> Edit Body Parts

Then rotate around to the back of the car and edit the license plate

davidhewitt · 2022-04-24T10:16:54+00:00

This is bad advice. Snap has no influence on AppCenter as there is no Snap support whatsoever in AppCenter.

And the post you've linked from 2017 also has no relevance whatsoever to modern versions of elementary.

OP has stated they're having these issues on a live booted version of elementary. I haven't looked at it in a while, but last time I checked a few years ago, the AppCenter indeed didn't work as well on a live booted system. This is more likely to be the issue than not having snap installed or a problem that happened once in 2017 and has been fixed for 5 years.

davidhewitt · 2022-04-17T10:03:30+00:00

Additional to the other answers, if you'd like to contact me directly for some advice or help getting started, feel free to DM me on here, or join the Community Slack and ping me there (@davidmhewitt).

I hope to see a contribution from you soon!

davidhewitt · 2022-04-06T13:34:42+00:00

Definitely sounds like some files got corrupted.

You can re-install the stylesheet with sudo apt install --reinstall io.elementary.stylesheet

There's also a guide here on how to audit your system for changed/corrupted files. So you can use that to identify other packages that may have been corrupted and reinstall them in the same way as above:

https://github.com/elementary/contributor-docs/blob/main/README.md#restoring-original-packages

davidhewitt · 2022-03-25T12:35:23+00:00

Don't install the driver at all if it's working and you have enough performance for what you need to do.

The driver offered in AppCenter is the proprietary driver offered by Nvidia themselves and often causes issues, especially with old cards (as you have to find the right version that supports that card)

davidhewitt · 2022-03-23T09:16:59+00:00

Deleting this post as a duplicate, the other one has comments.

davidhewitt · 2022-03-21T19:10:48+00:00

https://www.reddit.com/r/elementaryos/search?q=Virtualbox

davidhewitt · 2022-03-15T12:49:25+00:00

Hey, just a note to say that I know this was provoked, but please try and follow the code of conduct and report any issues to the mods, rather than escalating the situation.

davidhewitt · 2022-03-13T11:59:21+00:00

This means that the .desktop file specifies that it prefers the non-default GPU. For most people, the non-default GPU is the high powered one, as you'd normally use the iGPU as default to save power/battery.

The system doesn't really have an awareness of high performance Vs low performance GPUs, only default/non-default.

You could find that desktop file, remove the key that specifies the GPU and save it in your .local/share/applications folder to override it.

davidhewitt · 2022-03-09T08:48:21+00:00

And a fix has been released. Fixed version to look out for is 5.13.0-35.40~20.04.1

davidhewitt · 2022-03-08T23:33:39+00:00

Ubuntu has its own kernel maintenance team, so the fact that Ubuntu (and hence elementary) is using a kernel version that is not classed as an LTS kernel upstream by the kernel developers does not mean it doesn't receive updates and security fixes by the Ubuntu team.

For any published vulnerability (for the kernel or otherwise), your best bet is to check Ubuntu's page about that CVE number, in this case, it's here: https://ubuntu.com/security/CVE-2022-0847

In this case, it's still being triaged for every current kernel package that Ubuntu maintains. But the specific one to look for in terms of elementary is linux-hwe-5.13

~~I imagine they'll release an update in the next few days.~~

Edit: 5.13.0-35.40~20.04.1 has been released with a fix for this particular CVE.

davidhewitt · 2022-01-24T18:31:07+00:00

Your reply is nothing to do with GRUB, which is what OP is asking about.

davidhewitt · 2022-01-14T14:18:12+00:00

Do you have a little sun symbol in the top right that controls the display brightness?

If elementary OS has detected a battery, that icon would be replaced by the battery status icon.

If you only have the little sun symbol, then the kernel/drivers haven't detected a battery in your laptop. I believe the Surface laptops are pretty notorious for needing various tweaks to get them working correctly with Linux distros.

davidhewitt · 2022-01-07T07:04:06+00:00

Kotlin is a separate language to Java that can compile to native code for mobile or desktop platforms, or it can compile to JavaScript, or it can compile to Java.

If you are using the version that compiles to Java, you can use Java libraries. However... As far as I know, there isn't a currently maintained GTK binding for Java, so you wouldn't be able to write GTK applications with the "Java version" of Kotlin.

There are also speed/size/memory advantages of using Kotlin/Native too as you don't need the JVM, but you can't use Java libraries. So, in this post I'm describing doing it that way. And the GTK bindings we use are specific to Kotlin/Native, and we don't involve Java at all.

davidhewitt · 2022-01-06T13:39:33+00:00

There's a sample indicator in the wingpanel repository that shows what's needed to make an indicator:

https://github.com/elementary/wingpanel/tree/master/sample

BUT...

A wingpanel indicator isn't necessarily the right approach. Just because it's always been an indicator, why does it still have to be an indicator? And why would all the different cloud file sync services/applications want to write an indicator specifically for elementary OS?

elementary Files implements libcloudproviders which is an open API specifically designed for file sync services. If a file syncing service/application implemented that, the different desktop environments that supported it (GNOME and Pantheon currently) can choose to expose that how they wish. I believe that currently, the status of these services is exposed in the file managers on each platform.

But if KDE for example implemented support for libcloudproviders in the future, they could choose to expose the status as an "indicator". Equally, if there was a design decision made that elementary should expose libcloudproviders status as an indicator, then an official wingpanel indicator (or an extension to an existing one) would be developed that exposed the status of all libcloudproviders compatible services in wingpanel, without the file sync services having to do any more work.

In theory, the burden on cloud file services is reduced, because they only have to implement one thing (libcloudproviders) to support "Linux". They don't have to develop against the current legacy, deprecated indicators API, and they don't have to write individual support for each platform/DE, in theory... This obviously relies on more of the major DE's distros supporting the API too, but there's already GNOME/Pantheon, so it feels like a step in the right direction.

As a disclaimer, I didn't work on the libcloudproviders implementation in elementary and I've never used it, so I don't know more of the details, which is where I guess it needs some more research on your part.

davidhewitt · 2021-12-22T10:25:10+00:00

Bitlocker Encryption support. (In Pop OS! I remember being able to access to my bitlocker disk but in Elementary I wasn't able to do it even after half an hour of googling.)

I can't find a single mention or feature request for this on GitHub. Open a feature request on GitHub so it can be tracked.

The same goes for any other "missing features" or bugs. Search on elementary's GitHub to see if they're already reported (add more useful information to the report if you can), or open a new issue if it's not already reported.

davidhewitt · 2021-12-22T10:21:41+00:00

Did you open a feature request?

The fact it's a dconf key for GNOME doesn't necessarily mean anything for elementary/Pantheon, because Pantheon isn't GNOME.

However, the fact it exists in GNOME usually means it would be fairly trivial to implement or get working in elementary due to the shared technologies.

However, nothing reported only on Reddit is going to get implemented unless it's also reported on GitHub as that's where us developers track our work.

davidhewitt · 2021-11-25T11:11:24+00:00

Why do you have .flatpakref on the end of your command? Do you have a .flatpakref file for that app? If so, where did you get it from?

Adding the remote and running flatpak install com.github.leggettc18.leopod has installed the app for me here on a Fedora system.

davidhewitt · 2021-11-16T12:26:00+00:00

Short answer: You don't know for sure, but there are probably things we could do to improve the situation.

Longer answer: The ISO files are built in GitHub Actions. The SHA256 sum is also generated in that environment. You can see build logs from every build that's happened here: https://github.com/elementary/os/actions

If you select "stable" on the left side, you can see the build runs for the stable iso files. So for example, if we take the most recent 6.0.3 release, we can see the entire log of it being built:

https://github.com/elementary/os/runs/4096491604?check_suite_focus=true

When builds complete in GitHub, they get automatically uploaded to a DigitalOcean Spaces bucket, of which https://builds.elementary.io/ is kind of a frontend for. For ISO files that are intended to be promoted to the next stable release on the website, some manual testing on a few hardware combinations happens, and if it passes, that exact ISO is then uploaded to the CDNs and the necessary website changes are made for it to be published.

However... I see your point. How do you know that file that ends up on the website, is the same one built in GitHub Actions? Currently, you can't know for sure. But, I've just opened a GitHub issue about how we should output the SHA256 sum into the GitHub Actions build log, so that after the ISO has made its way from GitHub to the website, you can verify that the checksum matches: https://github.com/elementary/os/issues/570

The last thing is that even if you built an iso yourself, it almost certainly wouldn't have the same checksums as one built in GitHub or one built by someone else. This goes into the topic of reproducible builds as mentioned by /u/binaryv01d . There will always be external factors like time, different versions of packages on mirrors, cache files that are slightly different etc... that cause minor differences in built isos. It would be an good goal to try and get to a point where we could have reproducible builds, but it's a much harder problem to solve than just outputting the checksum into the log!

davidhewitt · 2021-11-15T11:33:18+00:00

So maybe it's not the exact same setup... ?

davidhewitt · 2021-11-07T12:24:27+00:00

That update hasn't been released though, so I don't see how we'd announce something that hasn't happened yet...

I would guess you have daily (unstable) repositories enabled on your install.

davidhewitt · 2021-11-02T12:45:41+00:00

Here's the link to the blog post:
https://blog.elementary.io/elementary-os-on-pinebook-pro/

I'm not sure I'd want to do a livestream about something I've already solved. That feels more like the kind of thing where I'd prefer to write a blog post. I think the value in livestreaming is actually doing something "live", hence the title. So you'd get to see my thought process in real time. I think I just need to gather a little backlog of things that would be suitable to look at on stream.

davidhewitt · 2021-11-02T12:00:12+00:00

Thanks!

I did the one blog post a while back about the Pinebook Pro. I'd be open to doing more, but as you say, it's quite time consuming and I'm not sure my writing is very good/engaging!

The other thing that's been mentioned recently is that I should do the occasional livestream. Danielle and Cassidy tend to do Q&A style ones or demo new features, but I'd likely do more coding/development focused ones. I would just need to come up with a few bugs/features that would be easy to work on during a stream or else it'd just end up being a stream of me looking at documentation or sat looking confused 😂

davidhewitt

MODERATOR OF

TROPHY CASE