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.

Sign up for GitHub

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

Jump to bottom

Lacks a simple uniform interface for basic cases #4

Closed
sjudd opened this issue Jul 16, 2013 · 1 comment
Closed

Lacks a simple uniform interface for basic cases #4

sjudd opened this issue Jul 16, 2013 · 1 comment
Labels
feature

Comments

@sjudd
Copy link
Collaborator

sjudd commented Jul 16, 2013

It should be easier to request loads for files on disk or at urls.
@sjudd sjudd closed this as completed Jul 17, 2013
@sjudd sjudd reopened this Jul 17, 2013
@sjudd
Copy link
Collaborator Author

sjudd commented Jul 18, 2013

Added in d76f655

@sjudd sjudd closed this as completed Jul 18, 2013
@zhfnjust zhfnjust mentioned this issue Sep 16, 2015
Closed
@petrovichtim petrovichtim mentioned this issue Nov 10, 2016
Closed
@linyongsheng linyongsheng mentioned this issue Mar 13, 2017
Closed
@b0g8 b0g8 mentioned this issue Mar 31, 2017
Closed
@wss991 wss991 mentioned this issue Sep 20, 2017
Closed
@AndroidDeveloperLB AndroidDeveloperLB mentioned this issue Sep 26, 2017
Closed
@MKevin3 MKevin3 mentioned this issue Nov 1, 2017
Closed
This was referenced Nov 20, 2017
Closed
Closed
@yanchengdeng yanchengdeng mentioned this issue Dec 5, 2017
Closed
@he4330937 he4330937 mentioned this issue Dec 27, 2017
Open
@AllenVork AllenVork mentioned this issue Jul 12, 2018
Closed
@mushtaq99 mushtaq99 mentioned this issue Sep 5, 2018
Closed
@hellowwwwp hellowwwwp mentioned this issue Dec 28, 2018
Closed
@GarikKhachaturyan GarikKhachaturyan mentioned this issue Dec 2, 2019
Closed
@arbelkf arbelkf mentioned this issue Feb 26, 2020
Closed
@perracodex perracodex mentioned this issue Mar 30, 2020
Closed
@MarsToken MarsToken mentioned this issue Apr 20, 2020
Closed
@shenmaoqing shenmaoqing mentioned this issue Dec 9, 2020
Closed
@shaoguanglin shaoguanglin mentioned this issue Jul 9, 2021
Open
@xwjhlhc xwjhlhc mentioned this issue Aug 26, 2021
Open
@OneOfBillions OneOfBillions mentioned this issue Jan 11, 2022
Open
@Steven-Yao Steven-Yao mentioned this issue Apr 11, 2022
Open
sjudd referenced this issue in sjudd/glide Jul 6, 2022
@sjudd
Add a basic KSP Symbol Processor for Glide
7489bc0 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.
@sjudd sjudd mentioned this issue Jul 6, 2022
Closed
sjudd referenced this issue in sjudd/glide Jul 6, 2022
@sjudd
Add a basic KSP Symbol Processor for Glide
9b7cf7f 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.
sjudd referenced this issue in sjudd/glide Jul 6, 2022
@sjudd
Add a basic KSP Symbol Processor for Glide
1db1e62 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.
sjudd referenced this issue in sjudd/glide Jul 7, 2022
@sjudd
Add a basic KSP Symbol Processor for Glide
fd32ad0 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.
@copybara-service copybara-service bot mentioned this issue Jul 14, 2022
Merged
copybara-service bot pushed a commit that referenced this issue Jul 14, 2022
@sjudd @glide-copybara-robot
Add a basic KSP Symbol Processor for Glide
079ee9a 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.

PiperOrigin-RevId: 460850418
copybara-service bot pushed a commit that referenced this issue Jul 19, 2022
@sjudd @glide-copybara-robot
Add a basic KSP Symbol Processor for Glide
c9f9c8f 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.

PiperOrigin-RevId: 460850418
copybara-service bot pushed a commit that referenced this issue Jul 19, 2022
@sjudd @glide-copybara-robot
Add a basic KSP Symbol Processor for Glide
6469702 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.

PiperOrigin-RevId: 460850418
copybara-service bot pushed a commit that referenced this issue Jul 19, 2022
@sjudd @glide-copybara-robot
Add a basic KSP Symbol Processor for Glide
c35ad13 
This library only implements support for basic configuration of Glide. Like the
Java version it can detect and merge multiple LibraryGlideModules and a single
AppGlideModule. The merged output (GeneratedAppGlideModule) will then be
called via reflection to configure Glide when Glide is first used.

Unlike the Java version this processor has no support for:

1.  Extensions
2.  Including or Excluding LibraryGlideModules that are added via AndroidManifest registration
3.  Generated Glide, RequestOptions, RequestBuilder, and RequestManager
    overrides.
4.  Excluding LibraryGlideModules that are added via annotations

I suspect very few people use the first two missing features and so,
barring major objections, those features will be only available via the
Java processor and in the very long run, deprecated. Kotlin extension
functions can provide the same value with less magic and complexity as
Extensions. AndroidManifest registrtion has been deprecated for years.

For #3 ideally we do not support these generated overrides either. Their
only real purpose was to expose the functionality provided by
Extensions. The one caveat is that our documentation has encouraged
their use in the past. If we remove support instantly, it may complicate
migration.

I will support #4, but in a future change. This one is large enough
already.

PiperOrigin-RevId: 461943092
@WSWSKIM WSWSKIM mentioned this issue Apr 8, 2023
Open
@mngzb339 mngzb339 mentioned this issue Dec 21, 2023
Open
@jackeysun6032 jackeysun6032 mentioned this issue Mar 11, 2024
Open
@Fossor Fossor mentioned this issue Mar 12, 2024
Open
@Softtanck Softtanck mentioned this issue May 9, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@sjudd @TWiStErRob