-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
[Editor Help] Add support for embedded and remote images in the class reference pages. #69751
base: master
Are you sure you want to change the base?
Conversation
7a86d2c
to
25352f4
Compare
25352f4
to
a2c8780
Compare
If we decide to bundle some images with the built-in docs, I'm not sure we're going to use themes or the |
Why not, if we will use bundled images it would only make sense for lightweight SVG diagrams which would benefit from using theme colors. But it's two lines of code, so removed it for now. |
a2c8780
to
0caf21f
Compare
0caf21f
to
86834df
Compare
Should |
86834df
to
d03e074
Compare
I recommend embedding svg images if possible. There may be a processing cost though.. Not sure |
d03e074
to
f7e40d8
Compare
Added
Updated to make request with |
f7e40d8
to
7d9a255
Compare
There is full intention to use images in the documentation, it's important. Feature doesn't need to be bundled with content it enables, because frankly it's not bruvzg's concern to add this content. This is a big side-track about nothing at this point.
It needs to be updated as is, as it doesn't include export templates. And it doesn't mention that we use GitHub now (and who knows what they collect). |
Well, that's your point of view, and dismissing my point like that is quite uncalled for. I believe this is a very important topic, that deserves proper discussion. Anyway, I explained my concerns, I rest my case. |
I'm not dismissing your concerns. In fact, I've addressed them and presented solutions. I'm simply pointing out that they aren't related to this PR which adds a needed feature. It doesn't define how we would use it, and it can't in any way update the privacy policy on the website. It's a separate task that can only be coordinated and performed after we have the feature ready. |
From what I see the request is that:
Block this pr. |
Disabling image loading by default, or prompting to ask for download, is totally part of this feature, and should be part of the PR.
No, updating the Privacy Policy does not depend on this PR, and can (and should) be done before it. |
Not sure if fully disabling by default is the best option, I would do And This way users will be aware of the options and nothing is loaded without consent. |
No, it cannot be done before if we don't intend to merge this PR because you are blocking it. The privacy policy should reflect only what's actual.
This PR implements the framework for better handling of images embedded into the docs. It doesn't have to also implement an entirely separate framework for managing user preferences about internet privacy. Because it doesn't add images itself. A follow-up can deal with that, implemented by anybody. |
Optional loading probably should be implemented in this PR, it's not adding any images, but enables third-party plugins/scripts with documentation to use this feature. |
The way I view it, privacy is a bigger problem than just help. Asset library is way worse and more concerning, because it deals with 3rd party content. So I think the option should be to disable all internet activity by default and display appropriate GUI elements that there is web content that can be loaded should the user choose to, explaining the implications. So I wouldn't bother too much with granular settings for the help specifically, since the asset library would be even more complicated with images that don't have to pass through a strict validation that applies to engine contributions. |
As mentioned before, plugins and scripts can do much worse things than load images from the internet. Same as testing user created games, for instance. This is always a danger and something we must also address in a more global, general way. |
That's not how privacy policy works.
Privacy policies MUST be updated before features are implemented, to give
time to the users to be informed (which I admit, in the case of Godot is
hard to estimate how long it is, but definitely not AFTER the fact).
…On Mon, Aug 7, 2023, 20:44 Yuri Sizov ***@***.***> wrote:
No, updating the Privacy Policy does not depend on this PR, and can (and
should) be done before it.
No, it cannot be done *before* if we don't intend to merge this PR
because you are blocking it. The privacy policy should reflect only what's
actual.
Disabling image loading by default, or prompting to ask for download, is
totally part of this feature, and should be part of the PR.
This PR implements the framework for better handling of images embedded
into the docs. It doesn't have to also implement an entirely separate
framework for managing user preferences about internet privacy. Because it
doesn't add images itself. A follow-up can deal with that, implemented by
anybody.
—
Reply to this email directly, view it on GitHub
<#69751 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4C3SNHHW32OZZAO7RPKTXUEZQFANCNFSM6AAAAAASX2UYSY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
But we can't update it if you block the PR and therefore the feature would never be allowed, Fabio. It's a catch 22. We first must agree on this PR, we can't update the policy before that. |
You can absolutely update it, I don't understand why you keep saying you
can't.
The fact that you say that you can collect info in one scenario doesn't
mean you must do that.
Also, the asset library and the help setting should definitely be separated.
They are 2 different things, with a different threat model.
And forcing people to an all or nothing makes no sense.
Email apps asks you to download images, they don't tie that to also
disabling extensions support.
They are two completely different things.
…On Mon, Aug 7, 2023, 20:51 Yuri Sizov ***@***.***> wrote:
That's not how privacy policy works. Privacy policies MUST be updated
before features are implemented, to give time to the users to be informed
(which I admit, in the case of Godot is hard to estimate how long it is,
but definitely not AFTER the fact).
But we can't update it if you block the PR and therefore the feature would
never be allowed, Fabio. It's a catch 22. We first must agree on this PR,
we can't update the policy before that.
—
Reply to this email directly, view it on GitHub
<#69751 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4C3UJDX7HV2OJUKGURFDXUE2JRANCNFSM6AAAAAASX2UYSY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Its probably time for everyone to take a step back from this discussion. It is clear there are some non-technical issues that require discussion. This isn't the kind of change that can be made without a proper discussion including relevant stakeholders. But to center the discussion (which should take place in a different place):
|
I can suggest, given this PR also adds other features too, notably:
That we could strip the http(s) download part from this PR, while leaving the above features. And move the download part ( |
Seconding @Faless - I totally missed the "remote images" part and was looking forward to seeing local images in help. |
Extracted RTL only part to #80410 I'll update this PR with the main client like remote content prompts a bit later. |
Was |
Following up #69712 (comment)
[img]http(s)://image_url[/img]
in the documentation, to load remote images (downloaded and cached).Usage Example
Screen.Recording.2022-12-08.at.10.10.08.mov