use a URI type from a library instead of plain Strings about ashpd

[Be-ing]

I disagree. It would be better to prevent passing invalid URLs by using a URL type as the input.

[bilelmoussaoui]

The latest zvariant release implement the necessary types for us to make use of url::Url type.

[bilelmoussaoui]

I don't think it is useful to depend on an external crate for this. But yes, having some very basic in-tree URI type that can be used instead of plain String would be nice. Do you want to submit a patch for that? There are not that many usages that I can think of.

Only Account, Screenshot & FileChooser returns a URI.

[Be-ing]

This would be a breaking API change. Would you want to make a new major release just for this? Or maybe wait and do this together with other breaking changes?

[bilelmoussaoui]

This would be a breaking API change. Would you want to make a new major release just for this? Or maybe wait and do this together with other breaking changes?

I am planning to make a new major release yes so it is fine to do breaking changes

[A6GibKm]

I am not sure this is the best idea. The user can always do

let uri = url::Url::parse("something")?;
some_ashd_portal(uri.into()).await?;

when verification is needed. But maybe forcing the parse on our side is a good idea?

[Be-ing]

For my use case I am more concerned with properly handling URIs read from ashpd. I was making mistaken assumptions about the returned data which the compiler let me do because it was a String. If its type conveyed it was a URI, that couldn't be ignored.

[bilelmoussaoui]

There is no URI inputs, only outputs btw. So we could have just a pub struct URI(String) & return that.

[A6GibKm]

Doesn't the uri portal require a url input

[bilelmoussaoui]

Doesn't the uri portal require a url input

Hmm yeah indeed.

[bilelmoussaoui]

there is also the wallpaper portal that takes a uri

[A6GibKm]

I think the best thing to do is to accept arbitrary strings, but return early (error) if, say, url::Url::parse(input) fails.