[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: First deprecate APIs and then remove them in the next major version
From: Daniel Kasak <d.j.kasak.dk () gmail ! com>
Date: 2017-12-17 23:14:06
Message-ID: CAF73Y=Qa2ZgOy4CyDvR4JKN-FxwVeUfr1f+EO9ad6PQQhf5NCA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, Dec 17, 2017 at 1:12 AM, Christian Schoenebeck <
schoenebeck@linuxsampler.org> wrote:
> On Samstag, 16. Dezember 2017 12:05:03 CET Sébastien Wilmet wrote:
> > On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote:
> > > I know this may sound harsh, but: If you want things to work
> differently,
> > > send patches.
>
> In theory. In practice you send patches and then you get a response like
> "hmm,
> not sure about that, I would like to have it differently", and that
> without an
> actual suggestion how to do that "differently".
>
> Like you said, if you want things differently, send your patches. But then
> as
> a patch sender you have the same expectation: you don't like the patch,
> make a
> better suggestion! You don't have a better suggestion or at least an
> adequate
> feedback? Ok, then apply the patch and simply add FIXME comment(s) at your
> own
> discretion and maybe one day somebody replaces it with a better solution.
>
> Just one example, gtk3 (yes 3, not even 4) is currently completely
> unusable on
> Mac, so I sent a patch to fix this:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=791174
>
> I know my patch is suboptimal, but to make this clear: it does not address
> a
> minor bug, this bug is a real show stopper on Mac, and this change is
> purely
> gtk internal. Of course it is not a clean solution, but there is no reason
> to
> simply apply this patch (at a bare minimum at least to the gtk3/stable
> branch)
> with a FIXME comment for now so that people on Mac can finally start using
> gtk3
> at all.
>
I really have to agree. One of my bugs I raised in 2004 - which involves
data loss - is still open. I submitted a patch ( which was difficult at the
time - I only dabble in C when I absolutely have to ) which received very
little feedback, and the bug has rotted since. I believe it exists in gtk+
versions 2 and 3, but I removed support for GtkComboBoxEntry widgets from
all my code when porting to version 3 to avoid the issue entirely.
"Send a patch" only goes so far. If patches don't get reviewed, or don't
get sufficient feedback, and never get accepted, what's the point in
sending patches?
Dan
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 17, 2017 \
at 1:12 AM, Christian Schoenebeck <span dir="ltr"><<a \
href="mailto:schoenebeck@linuxsampler.org" \
target="_blank">schoenebeck@linuxsampler.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On Samstag, 16. Dezember 2017 12:05:03 CET \
Sébastien Wilmet wrote:<br> > On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias \
Clasen wrote:<br> > > I know this may sound harsh, but: If you want things to \
work differently,<br> > > send patches.<br>
<br>
</span>In theory. In practice you send patches and then you get a response like \
"hmm,<br> not sure about that, I would like to have it differently", and \
that without an<br> actual suggestion how to do that "differently".<br>
<br>
Like you said, if you want things differently, send your patches. But then as<br>
a patch sender you have the same expectation: you don't like the patch, make \
a<br> better suggestion! You don't have a better suggestion or at least an \
adequate<br> feedback? Ok, then apply the patch and simply add FIXME comment(s) at \
your own<br> discretion and maybe one day somebody replaces it with a better \
solution.<br> <br>
Just one example, gtk3 (yes 3, not even 4) is currently completely unusable on<br>
Mac, so I sent a patch to fix this:<br>
<br>
<a href="https://bugzilla.gnome.org/show_bug.cgi?id=791174" \
rel="noreferrer" target="_blank">https://bugzilla.gnome.org/<wbr>show_bug.cgi?id=791174</a><br>
<br>
I know my patch is suboptimal, but to make this clear: it does not address a<br>
minor bug, this bug is a real show stopper on Mac, and this change is purely<br>
gtk internal. Of course it is not a clean solution, but there is no reason to<br>
simply apply this patch (at a bare minimum at least to the gtk3/stable branch)<br>
with a FIXME comment for now so that people on Mac can finally start using gtk3<br>
at all.<br></blockquote><div><br></div><div>I really have to agree. One of my bugs I \
raised in 2004 - which involves data loss - is still open. I submitted a patch ( \
which was difficult at the time - I only dabble in C when I absolutely have to ) \
which received very little feedback, and the bug has rotted since. I believe it \
exists in gtk+ versions 2 and 3, but I removed support for GtkComboBoxEntry widgets \
from all my code when porting to version 3 to avoid the issue \
entirely.</div><div><br></div><div>"Send a patch" only goes so far. If \
patches don't get reviewed, or don't get sufficient feedback, and never get \
accepted, what's the point in sending \
patches?</div><div><br></div><div>Dan</div></div></div></div>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic