After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 789871 - preset: Do not save deprecated properties
preset: Do not save deprecated properties
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal normal
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-11-03 15:22 UTC by Thibault Saunier
Modified: 2017-11-26 18:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
preset: Do not save deprecated properties (1002 bytes, patch)
2017-11-03 15:22 UTC, Thibault Saunier
committed Details | Review

Description Thibault Saunier 2017-11-03 15:22:33 UTC
See commit message.
Comment 1 Thibault Saunier 2017-11-03 15:22:37 UTC
Created attachment 362907 [details] [review]
preset: Do not save deprecated properties

It will g_warn uppong desarialization and we should not use
thos anyway.
Comment 2 Tim-Philipp Müller 2017-11-04 11:22:10 UTC
What will g_warn upon deserialisation? GstPreset? Some elements?

Arguably there could be a backwards-compatibility issue here - if someone only set the old version of some property and doesn't set the new one then we're dropping the setting entirely, no?

Unless we assume that elements will always configure their new versions right when the deprecated ones get set. Which might be a reasonable assumption/requirement to make.

Either way it's probably fine, since hardly anyone uses presets anyway ;)
Comment 3 Thibault Saunier 2017-11-04 12:30:44 UTC
(In reply to Tim-Philipp Müller from comment #2)
> What will g_warn upon deserialisation? GstPreset? Some elements?

Usually elements do.

> Arguably there could be a backwards-compatibility issue here - if someone
> only set the old version of some property and doesn't set the new one then
> we're dropping the setting entirely, no?

Yeah, I know that - I am not sure what would be best in that case.

> Unless we assume that elements will always configure their new versions
> right when the deprecated ones get set. Which might be a reasonable
> assumption/requirement to make.
> 
> Either way it's probably fine, since hardly anyone uses presets anyway ;)

Right, this is somehow my view also... I am not 100% convinced by that patch either tbh but I do not see what would be a good solution for that (we get spanned by g_warning in Pitivi when using encoders that have deprecated props (vp8 for example)).
Comment 4 Tim-Philipp Müller 2017-11-04 14:57:32 UTC
The only alternative I can think of would be a flag to say which properties should be saved for presets or not. There may be a bug about that, or maybe it was about ui hints for properties.
Comment 5 Thibault Saunier 2017-11-04 16:01:41 UTC
(In reply to Tim-Philipp Müller from comment #4)
> The only alternative I can think of would be a flag to say which properties
> should be saved for presets or not. There may be a bug about that, or maybe
> it was about ui hints for properties.

A flag to say what props should *not* be serialized could work, is it worth it? :-)
Comment 6 Thibault Saunier 2017-11-26 15:54:35 UTC
What would you do about that one?
Comment 7 Tim-Philipp Müller 2017-11-26 16:10:07 UTC
I'd say just go for it. If there's a problem in practice we can still fix it later :)
Comment 8 Thibault Saunier 2017-11-26 16:29:21 UTC
Attachment 362907 [details] pushed as 81e10f6 - preset: Do not save deprecated properties
Comment 9 Thibault Saunier 2017-11-26 18:26:53 UTC
Would backporting be OK? (so we avoid warning in Pitivi 1.0 - not a big deal anyway if you think we should not).