Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not show all text in IOS #39

Open
thienvu23 opened this issue Feb 1, 2024 · 15 comments
Open

Not show all text in IOS #39

thienvu23 opened this issue Feb 1, 2024 · 15 comments

Comments

@thienvu23
Copy link

image

@Arjan-Zuidema
Copy link

On an iPad it's even worse.
Schermafbeelding 2024-03-08 om 12 33 26

The toast could be a lot wider or even higher. And it should never break words as it shows important messages.

@kurucaner
Copy link
Contributor

I'm having the same issue. Any update on this?

@kurucaner
Copy link
Contributor

@nandorojo Is this something you can help us figure out?

@nandorojo
Copy link
Owner

nandorojo commented Mar 19, 2024

Hey just a kind reminder not to ping for open source.

The issue lies in the upstream native library we use. If they allowed longer text then we could too.

Keep in mind toast messages must be very short by design, as it's fleeting UI.

@kurucaner
Copy link
Contributor

Thanks for the response nandorojo. I didn't mean to disturb.

@Arjan-Zuidema
Copy link

Hey just a kind reminder not to ping for open source.

Imo when you create a package you should respond to issues.

The issue lies in the upstream native library we use. If they allowed longer text than we could do.

If only you just reacted with this, it would be fine.

Keep in mind toast messages must be very short by design, as it's fleeting UI.

This is very opinionated, imo it should also be possible to add the whole lorum ipsum

@nandorojo
Copy link
Owner

Imo when you create a package you should respond to issues.

While it’s fine for that to be your opinion, giving away my code for free doesn’t necessitate also giving away my time for free.

I maintain a lot of packages and have a better response rate than most developers. It’s a lot of work, and it’s meant to be collaborative. That’s why you can read the code and send PRs.

As a common practice, if you want more help with an open source issue, you can sponsor or offer to pay to prioritize an issue. Otherwise, you should just expect regular response times.

And FWIW, maintainers are always more likely to help someone who is courteous. And even more someone who contributes to libraries / releases their own libraries.

If only you just reacted with this, it would be fine.

And that’s what I did.

If you want the info in less than a few days, all you have to do is open the code. It’s fine to ask questions and not want to spend time doing that if you’re willing to wait. But keep in mind that that’s always possible.

This is very opinionated, imo it should also be possible to add the whole lorum ipsum

It is indeed. But it’s inline with how Apple’s toasts work too.

I have nothing against showing more text if the upstream library would allow it. But I’m just guessing that this is why they did it that way.

It probably makes sense to open an upstream issue and link it here.

@nandorojo
Copy link
Owner

Thanks for the response nandorojo. I didn't mean to disturb.

@kurucaner no worries, just trying to keep my GitHub notifications from exploding is all. Thanks for the PR, will take a look.

@kurucaner
Copy link
Contributor

Thanks for the response nandorojo. I didn't mean to disturb.

@kurucaner no worries, just trying to keep my GitHub notifications from exploding is all. Thanks for the PR, will take a look.

I'm loving all the packages you are sharing. Moti, zeego, and burnt are really very useful projects. Thank you so much for your time. I'm hoping to contribute more in the future.

@nandorojo
Copy link
Owner

nandorojo commented Mar 19, 2024

Glad they’re useful!

By the way I get the frustration when you urgently want a fix from open source and you’re stuck waiting. This is how I usually try to handle it:

Shopify/flash-list#824 (comment)

@kurucaner
Copy link
Contributor

kurucaner commented Mar 19, 2024

Glad they’re useful!

By the way I get the frustration when you urgently want a fix from open source and you’re stuck waiting. This is how I usually try to handle it:

Shopify/flash-list#824 (comment)

It's a very fair way of handling requests from open source projects. Thanks for the tip!

@nandorojo
Copy link
Owner

nandorojo commented Mar 19, 2024

Related issue: ivanvorobei/SPIndicator#29

@ivanvorobei
Copy link
Contributor

On an iPad it's even worse. Schermafbeelding 2024-03-08 om 12 33 26

The toast could be a lot wider or even higher. And it should never break words as it shows important messages.

You using wrong way to show important message

@ivanvorobei
Copy link
Contributor

Hey just a kind reminder not to ping for open source.

Imo when you create a package you should respond to issues.

The issue lies in the upstream native library we use. If they allowed longer text than we could do.

If only you just reacted with this, it would be fine.

Keep in mind toast messages must be very short by design, as it's fleeting UI.

This is very opinionated, imo it should also be possible to add the whole lorum ipsum

I hope you skip my open source and stuff that I did. Looks like instead of "thanks you" you think I owe you something. Not great at all

@Arjan-Zuidema
Copy link

First of all:

Hey just a kind reminder not to ping for open source.

Sounds kinda harsh, so that's the reason for my kinda harsh response.

Imo when you create a package you should respond to issues.

While it’s fine for that to be your opinion, giving away my code for free doesn’t necessitate also giving away my time for free.

I maintain a lot of packages and have a better response rate than most developers. It’s a lot of work, and it’s meant to be collaborative. That’s why you can read the code and send PRs.

As a common practice, if you want more help with an open source issue, you can sponsor or offer to pay to prioritize an issue. Otherwise, you should just expect regular response times.

And FWIW, maintainers are always more likely to help someone who is courteous. And even more someone who contributes to libraries / releases their own libraries.

I know it's a lot of time to maintain a package and I surely appreciate that as I also maintain packages (also for free in my free time). But not responding to issues for over a month looks bad. But that's just my opinion.

If only you just reacted with this, it would be fine.

And that’s what I did.

If you want the info in less than a few days, all you have to do is open the code. It’s fine to ask questions and not want to spend time doing that if you’re willing to wait. But keep in mind that that’s always possible.

I don't expect it to be fixed in a few days, but it seems like little effort to reply like you just did within a few days instead of after a month. People depend on packages, and it can be frustrating when maintainers don't respond.
Also an answer that does not meet the response that people hope for is better than no response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants