Status Update
Comments
al...@gmail.com <al...@gmail.com> #2
Hi,
I also see my text cut off when I set maxLines = 2
. Is it the same issue?
Box(
modifier =
Modifier.size(
width = 108dp,
height = 34dp,
),
contentAlignment = Alignment.Center,
) {
BasicText(
text = "text text text",
maxLines = 2,
autoSize = AutoSize.StepBased(minFontSize = 1.sp, maxFontSize = 13.sp, stepSize = 0.2.sp),
)
}
al...@gmail.com <al...@gmail.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <
Link:
Fix TextAutoSize bug with maxLines = 1
Expand for full commit details
Fix TextAutoSize bug with maxLines = 1
We were overcaching the paragraphIntrinsics in MultiParagraphLayoutCache when mutating the style. For `AutoSizeStepBased` instances with biased windows (more values smaller/bigger than the optimal), this could result in performing layout with outdated intrinsics, and thus an outdated style and font size, without surfacing this in the TextLayoutResult.
Test: New MultiParagraphLayoutCacheTests and manual testing
Relnote: Fixed a bug in BasicText with TextAutoSize and maxLines set to 1.
Fixes: 376834366
Change-Id: Ic0450c763c5d764492995b44ee1fe570246a9689
Files:
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/text/modifiers/MultiParagraphLayoutCacheTest.kt
- M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/modifiers/MultiParagraphLayoutCache.kt
Hash: e1b712d78cc60384ed67a56c006148291ba146a6
Date: Tue Jan 07 18:52:26 2025
to...@gmail.com <to...@gmail.com> #4
#2, yeah, that's the same issue.
ra...@gmail.com <ra...@gmail.com> #5
Thanks @jossiwolf@google.com for fixing this! Do you know when the fix would be available for g3 apps?
de...@gmail.com <de...@gmail.com> #6
Moving the internal discussion offline. The bug is fixed and the fix available in snapshot builds. We will comment on this issue when the bug fix is included in a release.
ni...@gmail.com <ni...@gmail.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-beta01
androidx.compose.foundation:foundation-android:1.8.0-beta01
androidx.compose.foundation:foundation-jvmstubs:1.8.0-beta01
androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-beta01
ce...@gmail.com <ce...@gmail.com> #8
in...@gmail.com <in...@gmail.com> #9
de...@gmail.com <de...@gmail.com> #10
eb...@gmail.com <eb...@gmail.com> #11
ab...@gmail.com <ab...@gmail.com> #12
hi...@gmail.com <hi...@gmail.com> #13
m4...@gmail.com <m4...@gmail.com> #14
jo...@gmail.com <jo...@gmail.com> #15
This feature would allow "true syncing" between systems where what is on Google Photos matches another source, such as a folder/subfolders on someone's local machine. Without this feature the API is only "send and see what is there"
fi...@gmail.com <fi...@gmail.com> #16
po...@gmail.com <po...@gmail.com> #17
And because CRUD support on API is a basic functionality for any client application working with photos, I hope this feature will be recognized as a high priority
Thank you
bi...@gmail.com <bi...@gmail.com> #18
pe...@gmail.com <pe...@gmail.com> #19
th...@gmail.com <th...@gmail.com> #20
tp...@gmail.com <tp...@gmail.com> #21
bl...@gmail.com <bl...@gmail.com> #22
mp...@gmail.com <mp...@gmail.com> #23
ek...@myzoss.com <ek...@myzoss.com> #24
di...@gmail.com <di...@gmail.com> #25
jf...@google.com <jf...@google.com> #26
We are currently considering the feasibility of adding an option to remove media items you have created from an album. Would that enable your use cases?
If you have any other specific use cases (beyond album/file management) that would not be supported by this call, please let us know.
Deleting media from the library entirely is not something we would be supporting in the short-term due to the potential for abuse.
ec...@gmail.com <ec...@gmail.com> #27
Authentication + limits on deletion per day would surely mitigate abuse.
jo...@gmail.com <jo...@gmail.com> #28
This is a request to be able to delete an item from the library entirely.
al...@gmail.com <al...@gmail.com> #29
Alternatively, enable a post request to replace the content of the media item
li...@gmail.com <li...@gmail.com> #30
jf...@gmail.com <jf...@gmail.com> #31
What "abuse' do you worry about? EVERY photo-hosting site I've worked with over the last 15 years allows authenticated third-party apps to add and delete images. Every one. Zenfolio, Flickr, SmugMug, Photobucket, your own now-defunct PicasaWeb, Ipernity, Facebook, Tumblr, ExposureManager, DeviantArt, Expono, 500px, among others.
Google's "Drive" API allows authenticated third-party apps to delete any item (including any photo) in the user's data. Their API has been around a long time, and is mature, and is actually usable. Perhaps use it as a model.
ch...@gmail.com <ch...@gmail.com> #32
My wife and I are setup to share photos with each other and we both have the "automatically save" feature turned on. This is perfect - we love being able to each search and see ALL the thousand of photos of our kids and dog and... that's it we don't have time to take photos of anything else but our kids and our dog.
But when we take photos, we don't take 1. We take 20 photos of the same setup to ensure that everyone has their eyes open, isn't moving, isn't coughing etc. Here's the problem. When we go to pick the one best shot, we are now stuck with 19 TERRIBLE OR DUPLICATE PHOTOS cluttering up our experience. They are in searches, they are in montages. We don't want them. We want the one good one. The problem is, because the photos are essentially duplicated across our libraries, we would each need to do all the work of, having picked the best one, getting rid of the rest.
SO, +1 for this API so I can add this functionality in myself. Close second would be an API allowing me to at least archive. But for me, the best (because again we don't have a bunch of time) would be a product solution that fixes this for my family without me having to build it using the API. Hope this gives some perspective on a possible use case for delete / archive in the API. For what it's worth, I think the Apple on-device API does a good job in this regard, by requiring an Apple controlled UI to be displayed, requiring explicit user consent before allowing each bulk delete request (this is the experience inside Google Photos when freeing up space). I can't recall any example of this kind of delegated UI in a more distributed web based API... but I bet it could be done! (And a few examples are actually coming to mind where an API requires a web-based service controlled UI... login via Google / Facebook / OAuth / etc. for one!) As one possible solution out of many for how this could be done. This was way too long, sorry.
me...@therealjuanmartinez.com <me...@therealjuanmartinez.com> #33
tr...@gmail.com <tr...@gmail.com> #34
I'm working on a system/app to remedy that problem. I have managed to find a way to work around the limitation of no delete API.
It's kind of a "locate similarity and enable users an easy way to delete masses of similar photos themselves" program, specific to google photos API.
The system/app scans your google photos library and detects similar* photos. I've developed a proof of concept and am tuning some parameters.
* the definition of similar is both an art and a science. I'm trying to increase the accuracy of my algorithms. Studying image processing as a result :P
If you're interested, drop me a line:
(I could only use "kcaptcha" on that site)
gi...@gmail.com <gi...@gmail.com> #35
si...@gmail.com <si...@gmail.com> #36
ad...@gmail.com <ad...@gmail.com> #37
st...@googlemail.com <st...@googlemail.com> #38
re...@gmail.com <re...@gmail.com> #39
fe...@gmail.com <fe...@gmail.com> #40
sl...@gmail.com <sl...@gmail.com> #41
al...@pomortsev.com <al...@pomortsev.com> #42
so...@gmail.com <so...@gmail.com> #43
dm...@gmail.com <dm...@gmail.com> #44
ru...@gmail.com <ru...@gmail.com> #45
wa...@gmail.com <wa...@gmail.com> #46
al...@gmail.com <al...@gmail.com> #47
ap...@gmail.com <ap...@gmail.com> #48
m....@gmail.com <m....@gmail.com> #49
ch...@gmail.com <ch...@gmail.com> #50
qw...@gmail.com <qw...@gmail.com> #51
fo...@gmail.com <fo...@gmail.com> #52
vl...@gmail.com <vl...@gmail.com> #53
[Deleted User] <[Deleted User]> #54
ar...@gmail.com <ar...@gmail.com> #55
tr...@gmail.com <tr...@gmail.com> #56
Enough people have asked me so I figured I'd share.
This isn't exactly a programmatic way to delete photos, but it's better than nothing and is a decent fit for my use case.
Here's the best workflow I found:
When you list photos using the API,
Each image you get from the API has a url associated with it. I've found that if you click on that link (using your browser, already signed in), you get directed to the page you'd see if you clicked on an individual photo in google photos.
You can then delete that individual photo from the Google Photos UI.
Added bonus is if you click the back button (inside Google Photos, not the browser) you are "fast-forwarded" to the location in the photo stream where the photo can be found.
For me, I'm looking for ranges of images, so this was a good best-effort way to seek to the image range in question.
I believe another idea would be to add the images you want to delete to an album, and then selecting all photos in the album and permanently deleting them from your photo collection.
I wasn't able to successfully execute on this one idea though. Don't remember why atm.
Good luck!
ph...@gmail.com <ph...@gmail.com> #57
je...@pinnix.net <je...@pinnix.net> #58
ze...@gmail.com <ze...@gmail.com> #59
al...@gmail.com <al...@gmail.com> #60
The only feedback we've had so far was that this is "not something we would be supporting in the short-term".
Does it mean it will be supported long term? If yes, then how long is long term?
If you are not going to support this full stop, then could you please put us out of misery and reject the FR.
It would also be nice to hear your reasoning. I can understand concerns where an app deletes an item created by another app - this indeed is open to abuse.
But why can't an app delete it's own item?
mp...@gmail.com <mp...@gmail.com> #61
I do not agree - Drive API has ability to delete whatsoever and nothing blown up yet.
Some response would be nice, we're helping you to get more of users data, which is your primary goal, after all....
al...@gmail.com <al...@gmail.com> #62
Sure, all I said is that I understand the concern. Clearly there would need to be additional safeguards in place, as for example I don't want your app to delete items created by mine. This is not necessarily trivial to implement on API side.
What I don't understand is why my app can't delete it's own items. I can't imagine this being hard to implement - the service clearly "remembers" which item was created by which app to handle the access control. So there is something else that stops them and it would be nice to hear what it is.
mp...@gmail.com <mp...@gmail.com> #63
It depends on use case. Of course I'm not saying that my app should delete your's app files - but if user intentionally want to do this - he should be able to.
po...@gmail.com <po...@gmail.com> #64
ro...@gmail.com <ro...@gmail.com> #65
My current use case:
1. Take many many photos in both my account account and my wife's account
2. Once in a while download all the photos from both of us using the Google Photos folder in Google Drive
3. Organize the downloaded media into folders according to timeline and delete bad photos
4. Upload the data back to Google Drive which also adds it to Google Photos
Since Google Photos isn't synced to Google Drive anymore I am seeking a programmatic way to do the above flow or similar.
Delete is a must to avoid our paid accounts to explode from unneeded media.
sa...@gmail.com <sa...@gmail.com> #66
li...@gmail.com <li...@gmail.com> #67
This is must needed functionality of basic CRUD feature of any API.
br...@gmail.com <br...@gmail.com> #68
bd...@gmail.com <bd...@gmail.com> #69
yo...@gmail.com <yo...@gmail.com> #70
kf...@gmail.com <kf...@gmail.com> #71
jf...@google.com <jf...@google.com> #72
We understand that this is an important feature for many of you. Having worked to understand the sensitivities that Google Photos users have around deletion, we've decided not to make this functionality available through the Google Photos Library API.
jf...@gmail.com <jf...@gmail.com> #73
je...@pinnix.net <je...@pinnix.net> #74
--but--
"we've decided not to make this functionality available through the Google Photos Library API."
Unbelievable.
"Having worked to understand the sensitivities that Google Photos users have around deletion"
Wait, maybe they didn't understand the original request? 🙄 This statement only makes sense if they thought we wanted access to delete any photos that live on Google Photos. The API requires authorization. You would have to explicitly be authorized to delete a photo.
tr...@gmail.com <tr...@gmail.com> #75
...
Wait..
No it's not :(
al...@gmail.com <al...@gmail.com> #76
Please reconsider this decision as it cripples Google Photo's usefulness and ability to integrate into more advanced workflows. I'd also add the Picasa API had this basic feature.
si...@gmail.com <si...@gmail.com> #77
mp...@gmail.com <mp...@gmail.com> #78
It's a basic CRUD functionality! Again - I'm not talking about randomly wiping user Photos, but options for this user to manually delete something.
ky...@gmail.com <ky...@gmail.com> #79
br...@gmail.com <br...@gmail.com> #80
[Deleted User] <[Deleted User]> #81
gu...@gmail.com <gu...@gmail.com> #82
[Deleted User] <[Deleted User]> #83
av...@gmail.com <av...@gmail.com> #84
Why not just mark them for deletion and put them in a Deleted folder for 30 days?
ni...@gmail.com <ni...@gmail.com> #85
ma...@titlis.org <ma...@titlis.org> #86
+1
ol...@zeltsergroup.com <ol...@zeltsergroup.com> #87
ju...@gmail.com <ju...@gmail.com> #88
f....@googlemail.com <f....@googlemail.com> #89
I'd really appreciate that feature!
mi...@gmail.com <mi...@gmail.com> #90
va...@gmail.com <va...@gmail.com> #91
go...@gmail.com <go...@gmail.com> #92
mr...@gmail.com <mr...@gmail.com> #93
ho...@gmail.com <ho...@gmail.com> #94
ju...@gmail.com <ju...@gmail.com> #95
do...@gmail.com <do...@gmail.com> #96
ab...@gmail.com <ab...@gmail.com> #97
fs...@gmail.com <fs...@gmail.com> #98
gu...@gmail.com <gu...@gmail.com> #99
Note Google have responded to say that they won't fix this, because, I think, of security concerns. They've also confusingly marked this feature request as "unfeasible".
ro...@gmail.com <ro...@gmail.com> #100
ro...@gmail.com <ro...@gmail.com> #101
jo...@gmail.com <jo...@gmail.com> #102
cr...@gmail.com <cr...@gmail.com> #103
zl...@gmail.com <zl...@gmail.com> #104
be...@gmail.com <be...@gmail.com> #105
gu...@gmail.com <gu...@gmail.com> #106
an...@gmail.com <an...@gmail.com> #107
gu...@gmail.com <gu...@gmail.com>
fr...@gmail.com <fr...@gmail.com> #108
As this issue is aging for years, I am getting out Google Photos of my Cloud Storage providers.
Bye-bye Google,
co...@gmail.com <co...@gmail.com> #109
As this issue is aging for years, I am getting out Google Photos of my Cloud Storage providers.
Bye-bye Google, -----
totally agree
bye bye I'll choose DRIVE Microsoft DRIVE
bu...@gmail.com <bu...@gmail.com> #110
re...@gmail.com <re...@gmail.com> #111
an...@gmail.com <an...@gmail.com> #112
og...@gmail.com <og...@gmail.com> #113
( +1 )
ju...@gmail.com <ju...@gmail.com> #114
ju...@gmail.com <ju...@gmail.com> #115
sa...@gmail.com <sa...@gmail.com> #116
sa...@gmail.com <sa...@gmail.com> #117
jo...@gmail.com <jo...@gmail.com> #118
Maybe also add an option to convert "Trash" images to "High Quality" so they aren't taking up space.
That would be a compromise I don't think even the most security-minded developer could object to.
s....@gmail.com <s....@gmail.com> #119
ma...@excloo.com <ma...@excloo.com> #120
[Deleted User] <[Deleted User]> #121
se...@gmail.com <se...@gmail.com> #122
ko...@gmail.com <ko...@gmail.com> #123
sh...@gmail.com <sh...@gmail.com> #124
ja...@gmail.com <ja...@gmail.com> #125
da...@gmail.com <da...@gmail.com> #126
na...@gmail.com <na...@gmail.com> #127
ad...@gmail.com <ad...@gmail.com> #128
[Deleted User] <[Deleted User]> #129
ps...@gmail.com <ps...@gmail.com> #130
ja...@seceidos.de <ja...@seceidos.de> #131
ha...@gmail.com <ha...@gmail.com> #132
ma...@gmail.com <ma...@gmail.com> #133
ed...@gmail.com <ed...@gmail.com> #134
ka...@googlemail.com <ka...@googlemail.com> #135
so...@gmail.com <so...@gmail.com> #136
al...@gmail.com <al...@gmail.com> #137
f....@googlemail.com <f....@googlemail.com> #138
ch...@gmail.com <ch...@gmail.com> #139
pe...@gmail.com <pe...@gmail.com> #140
to...@netamail.com.au <to...@netamail.com.au> #141
ni...@gmail.com <ni...@gmail.com> #142
bu...@gmail.com <bu...@gmail.com> #143
do...@gmail.com <do...@gmail.com> #144
rk...@gmail.com <rk...@gmail.com> #145
bm...@gmail.com <bm...@gmail.com> #146
fi...@gmail.com <fi...@gmail.com> #147
je...@gmail.com <je...@gmail.com> #148
wi...@gmail.com <wi...@gmail.com> #149
Was implementing some automation software around several photo storage providers and shocked to find I cannot support Google Photos at all with the inability of being able to remove photos from the service. I've been a supporter of Google Photos for years but with the upcoming change to no longer provide free high-quality storage, I think it's time to start using a new service moving forward as I don't like this direction at all.
rk...@gmail.com <rk...@gmail.com> #150
an...@gmail.com <an...@gmail.com> #151
fi...@gmail.com <fi...@gmail.com> #152
rk...@gmail.com <rk...@gmail.com> #153
zi...@gmail.com <zi...@gmail.com> #154
ba...@gmail.com <ba...@gmail.com> #155
mr...@gmail.com <mr...@gmail.com> #156
ji...@gmail.com <ji...@gmail.com> #157
mc...@gmail.com <mc...@gmail.com> #158
The Photos API is useless without this function...
an...@gmail.com <an...@gmail.com> #159
+1
mo...@gmail.com <mo...@gmail.com> #160
al...@gmail.com <al...@gmail.com> #161
ni...@gmail.com <ni...@gmail.com> #162
Have they changed the API so you cant remove pictures from an album?
g....@bonificarenana.it <g....@bonificarenana.it> #163
ne...@gmail.com <ne...@gmail.com> #164
gu...@gmail.com <gu...@gmail.com> #165
ka...@gmail.com <ka...@gmail.com> #166
The need to delete / move to recyclebin will increase more and more with storage limitation imposed with June 2021. Many customers, including me, are reconsidering alternatives for storage of photos.
Best Regards,
Ionut C.
ch...@gmail.com <ch...@gmail.com> #167
jl...@gmail.com <jl...@gmail.com> #168
el...@gmail.com <el...@gmail.com> #169
ba...@gmail.com <ba...@gmail.com> #170
"the ability to delete an image"
vl...@gmail.com <vl...@gmail.com> #171
fi...@gmail.com <fi...@gmail.com> #172
sc...@jacksonhome.net <sc...@jacksonhome.net> #173
It's easy to wind up with duplicated images - tens of thousands of them in my case (with hundreds of thousands of total images). Deleting these by hand is intractable. Please provide a delete function. If you are never going to, please let us know so we can decide where to go.
st...@gmail.com <st...@gmail.com> #174
st...@gmail.com <st...@gmail.com> #175
dh...@gmail.com <dh...@gmail.com> #176
du...@gmail.com <du...@gmail.com> #177
pg...@gmail.com <pg...@gmail.com> #178
av...@gmail.com <av...@gmail.com> #179
si...@gmail.com <si...@gmail.com> #180
cl...@gmail.com <cl...@gmail.com> #181
+1
I guess I would ask if deletion isn't a function you'd feel comfortable supporting, what are you supposed to do with this API?
Isn't the purpose to programmatically manage media on Google Photos?
gu...@gmail.com <gu...@gmail.com> #182
This (horrible) workaround does not work. Or at least only partially. An app can only assign media items to an album, which HAS BEEN UPLOADED BY THE APP. In other words, images uploaded by a user cannot be assigned.
I think this is horrific. And yes, the album must have been created by your app, too. (if there's a worse word than "horrific" I would've used it in this context)
Here's what's the API doc says (
<quote>Note that you can only add media items that have been uploaded by your application to albums that your application has created. Media items must also be in the user's library. For albums that are shared, they must either be owned by the user or the user must be a collaborator who has already joined the album.</quote>
ka...@gmail.com <ka...@gmail.com> #183
Even if only to use the API within our scripts to clean up media items which do not belong into any of the user created Albums.
eu...@gmail.com <eu...@gmail.com> #184
Without this functionality, I think I'll look elsewhere.
Too bad, would've liked to use Google :(
so...@gmail.com <so...@gmail.com> #185
re...@gmail.com <re...@gmail.com> #186
fa...@gmail.com <fa...@gmail.com> #187
am...@gmail.com <am...@gmail.com> #188
la...@ksperis.com <la...@ksperis.com> #189
gi...@gmail.com <gi...@gmail.com> #190
ka...@gmail.com <ka...@gmail.com> #191
fa...@gmail.com <fa...@gmail.com> #192
ma...@gmail.com <ma...@gmail.com> #193
st...@gmail.com <st...@gmail.com> #194
kk...@gmail.com <kk...@gmail.com> #195
ym...@gmail.com <ym...@gmail.com> #196
id...@gmail.com <id...@gmail.com> #197
ma...@aloi.com.br <ma...@aloi.com.br> #198
bo...@gmail.com <bo...@gmail.com> #199
al...@gmail.com <al...@gmail.com> #200
The photos an app uploads are anyway linked to it, so no reason why an app cannot delete photos it has uploaded.
What say ?
al...@gmail.com <al...@gmail.com> #201
an...@gmail.com <an...@gmail.com> #202
ja...@gmail.com <ja...@gmail.com> #203
status Infeasible? Only shows google being unwilling to actually do anything usefull for its users, and, only being there when they can aquire data... again. In my personal opinion.
[Deleted User] <[Deleted User]> #204
du...@gmail.com <du...@gmail.com> #205
dp...@lclark.edu <dp...@lclark.edu> #206
dp...@lclark.edu <dp...@lclark.edu> #207
Currently no API does not allow admin's or admin tools to manage users who have added hundreds of thousands of Google Photos while using an EDU account. The Google Drive API does not manage these files or allow admins to purge/delete them.
da...@gmail.com <da...@gmail.com> #208
ho...@gmail.com <ho...@gmail.com> #209
Safeguards can be put in place to prevent abuse. This is basic functionality that should be made available to consumers.
ch...@gmail.com <ch...@gmail.com> #210
an...@gmail.com <an...@gmail.com> #211
[Deleted User] <[Deleted User]> #212
05...@gmail.com <05...@gmail.com> #213
pr...@gmail.com <pr...@gmail.com> #214
ra...@gmail.com <ra...@gmail.com> #215
Cette fonctionnalité est essentielle.
Je suis très déçu par cette lacune alors que je paie mensuellement un forfait Google 10To !
Alain
ba...@gmail.com <ba...@gmail.com> #216
+1 please add this feature! maybe move to trash but not fully delete.
lu...@magazineluiza.com.br <lu...@magazineluiza.com.br> #217
au...@gmail.com <au...@gmail.com> #218
ts...@gmail.com <ts...@gmail.com> #219
er...@gmail.com <er...@gmail.com> #220
ga...@gmail.com <ga...@gmail.com> #221
la...@gmail.com <la...@gmail.com> #222
ve...@gmail.com <ve...@gmail.com> #223
This will never be implemented.
The reason is very simple. It would make people possible to easily cancel google one/drive. This way, if you have 100000 photos, uploaded in past 5-10 years and you decide to go for a NAS, they are forcing you to delete photos manually, in a small batches.
They even removed an option for linking photos to google drive folder. It doesn't exist any more.
va...@butanescu.com <va...@butanescu.com> #224
Additionally Google Photos and NAS storage aren't competing solutions. Google Photos isn't suited for any bulk storage management (see this ticket, while you can go on your NAS and just delete the pictures2022 directory immediately, but this isn't the only limitation) and in return NASes (or frankly any other self-hosted solution) don't come even close to what Google Photos does in terms of automatically recognizing faces, things, text (OCR!), places/maps and so on. But this is beside the point and a much larger and potentially subjective discussion.
he...@gmail.com <he...@gmail.com> #225
tr...@gmail.com <tr...@gmail.com> #226
tb...@gmail.com <tb...@gmail.com> #227
fr...@gmail.com <fr...@gmail.com> #228
I don't understand why the feature is not available in the first place.
pa...@desormeaux.org <pa...@desormeaux.org> #229
Google... Seriously???
v....@gmail.com <v....@gmail.com> #230
Maybe only for paid users???
Or add only move to bin, please!)
le...@gmail.com <le...@gmail.com> #231
jr...@gmail.com <jr...@gmail.com> #232
ba...@googlemail.com <ba...@googlemail.com> #233
go...@gmail.com <go...@gmail.com> #234
ma...@gmail.com <ma...@gmail.com> #235
de...@gmail.com <de...@gmail.com> #236
ma...@baba-jp.org <ma...@baba-jp.org> #237
Google made it very easy to flood users' storage with their photos and videos. When Google Photos app is installed on an iOS or Android device, it seems the "Backup" option is on by default. If the user has 15 GB of photos and videos on the device, the user's Google storage will be exhausted shortly.
Then Google provides a very easy way to purchase storage subscription. But Google does not provide a way to empty the storage.
fr...@gmail.com <fr...@gmail.com> #238
Are my photos no longer my own when I upload them to Google Photos? Why can I delete them using a browser but not using the API?
This makes no sense.
si...@gmail.com <si...@gmail.com> #239
[Deleted User] <[Deleted User]> #240
jj...@sigi.icu <jj...@sigi.icu> #241
Google photo team seems to ignore the basic things from the beginning and not listen to the users for most of the time.
mc...@gmail.com <mc...@gmail.com> #242
hu...@gapp.nthu.edu.tw <hu...@gapp.nthu.edu.tw> #243
sh...@gmail.com <sh...@gmail.com> #244
da...@weeden.ca <da...@weeden.ca> #245
mp...@aucklanduni.ac.nz <mp...@aucklanduni.ac.nz> #246
bi...@gmail.com <bi...@gmail.com> #247
zi...@gmail.com <zi...@gmail.com> #248
+1
pc...@gmail.com <pc...@gmail.com> #249
an...@gmail.com <an...@gmail.com> #250
ka...@gmail.com <ka...@gmail.com> #251
an...@gmail.com <an...@gmail.com> #252
al...@gmail.com <al...@gmail.com> #253
ro...@gmail.com <ro...@gmail.com> #254
ti...@liveinfo247.com <ti...@liveinfo247.com> #255
be...@gmail.com <be...@gmail.com> #256
ri...@zbulo.org <ri...@zbulo.org> #257
da...@gmail.com <da...@gmail.com> #258
ze...@gmail.com <ze...@gmail.com> #259
al...@gmail.com <al...@gmail.com> #260
dj...@gmail.com <dj...@gmail.com> #261
As it seems that there is no more answer from Google since years I guess solution is moving away
an...@gmail.com <an...@gmail.com> #262
ko...@gmail.com <ko...@gmail.com> #263
m_...@mail.uk <m_...@mail.uk> #264
ma...@gmail.com <ma...@gmail.com> #265
ma...@gmail.com <ma...@gmail.com> #266
lu...@gmail.com <lu...@gmail.com> #267
bm...@gmail.com <bm...@gmail.com> #268
to...@teamsports.co.nz <to...@teamsports.co.nz> #269
m....@gmail.com <m....@gmail.com> #270
jo...@sventus.com <jo...@sventus.com> #271
Not only delete, but being able to archive is also necessary! Please consider this feature!
la...@gmail.com <la...@gmail.com> #272
go...@gmail.com <go...@gmail.com> #273
fr...@gmail.com <fr...@gmail.com> #274
ro...@gmail.com <ro...@gmail.com> #275
jo...@googlemail.com <jo...@googlemail.com> #276
ka...@live.com <ka...@live.com> #277
After Google announcing this
Description
This basic functionality is required for apps that allow the user to maintain their photo library.
In my case, my app is for Adobe Photoshop Lightroom. For people who use Lightroom, Lightroom is the center of their photographic world. Lightroom users want to mirror albums in Lightroom to a remote service like Google Photos, but such mirroring requires the ability to remove a previously-added photo. I've made a dozen of these kind of "Lightroom-to-XXX" apps, for most photo-hosting sites you can imagine, but "Lightroom to Google Photos" is the one everyone keeps asking for.
The feature request
Thanks.