Re: gtk3 planning
Am Fri, 25 Jun 2010 14:12:00 -0400 schrieb Colin Walters : > On Fri, Jun 25, 2010 at 12:50 PM, Matthias Clasen > wrote: > > > > Sure, we could continue to shoehorn features in to 2.x and it will > > increasingly get harder, and the bugs will increasingly get harder > > to fix. > > What we need to *realistically* look at is what big features that > aren't going to make 3.0 now will be able to land later without ABI > breaks. Luckily some of us started to plan that already months ago, otherwise we would really be in trouble now. There was never any requirement to land everything we could ever want into the very first 3.0 release. > > Fwiw, a big motivation for all the sealing business was to make it > > possible that GTK3 _can_ move faster and incorporate more new stuff > > without the need for disruptive ABI breaks. > > Can say davidz's RI stuff land post-3.0? Can "Full support for MPX > and multitouch devices." Can "Revamp/rewrite the entire theming > system."? > > I think the answer to all of those is "no". While I know some MPX > code landed, as far as I'm aware none of the widgets have been updated > to possibly take advantage of it. Do we really believe that we can do > that (easily) in an API compatible way? Yes. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why is GCompletion deprecated
Hello GLib devs, I upgraded to latest glib, and I discover that GCompletion is now deprecated. Empathy was using it to complete the nickname when hitting TAB in chatrooms. I see nothing to replace that API... am I supposed to copy/paste its code inside Empathy?!? Is there a good reason to deprecated that code?!? Regards, Xavier Claessens. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Le 28/06/10 11:56, Xavier Claessens a écrit : Hello GLib devs, I upgraded to latest glib, and I discover that GCompletion is now deprecated. Empathy was using it to complete the nickname when hitting TAB in chatrooms. I see nothing to replace that API... am I supposed to copy/paste its code inside Empathy?!? Is there a good reason to deprecated that code?!? When discussing this on IRC, Emmanuele Bassi said that API is barely used, is not maintained and has bugs that needs API break to fix. But: 1) I can think a bazillion of UIs that do/should have completion. Maybe they can do that completion with something else than GCompletion, but then the deprecation warning in the gtk-doc should point to that other API. Probably GtkEntryCompletion is useful here, but can it be used with editable GtkTextView (what empathy uses to write IM)? 2) If all unmaintained code should be deprecated with no replacement, what do we have left in glib/gtk? Probably not that much... 3) What are the issues with current GCompletion exactly? It works pretty well in empathy's case at least. I would like to know the issues so we can think about better API to replace GCompletion. Surely good reasons where discussed with the community before deprecating the API, but I didn't find public discussion. If I missed it, please just give me the link ;-) Regards, Xavier Claessens. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote: > > 2) If all unmaintained code should be deprecated with no replacement, > what do we have left in glib/gtk? Probably not that much... That sort of comments has no place here, and hardly helps people feel any sympathy for your current conundrum. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote: > 1) I can think a bazillion of UIs that do/should have completion. the fact that nobody implemented them using GCompletion should give a hint that: a) this is not a shared opinion and b) it probably wasn't possible with GCompletion. > Maybe > they can do that completion with something else than GCompletion, but > then the deprecation warning in the gtk-doc should point to that other > API. Probably GtkEntryCompletion is useful here, but can it be used with > editable GtkTextView (what empathy uses to write IM)? please, come up with a better API; since I very much doubt you can fix GCompletion to actually be useful for everyone, it would still require a deprecation of the GCompletion API. > 2) If all unmaintained code should be deprecated with no replacement, > what do we have left in glib/gtk? Probably not that much... that is patently an hyperbole, and it's patently untrue. the deprecated code has been dropped from gtk+ 3.x and we still have a huge API footprint. > Surely good reasons where discussed with the community before > deprecating the API, but I didn't find public discussion. If I missed > it, please just give me the link ;-) I seem to have lost the memo requiring public discussion with the community for a maintainership decision. probably my bad. can you point me to it? ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
On Mon, 2010-06-28 at 14:49 +0100, Emmanuele Bassi wrote: > On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote: > > > 1) I can think a bazillion of UIs that do/should have completion. > > the fact that nobody implemented them using GCompletion should give a > hint that: a) this is not a shared opinion and b) it probably wasn't > possible with GCompletion. You know this categorically? Under my own submission, the GtkEntryCompletion does cover most things I ever needed. But I was quite surprised to read Xavier's email this morning. I would have thought this was quite useful/used. > > Maybe > > they can do that completion with something else than GCompletion, but > > then the deprecation warning in the gtk-doc should point to that other > > API. Probably GtkEntryCompletion is useful here, but can it be used with > > editable GtkTextView (what empathy uses to write IM)? > > please, come up with a better API; since I very much doubt you can fix > GCompletion to actually be useful for everyone, it would still require a > deprecation of the GCompletion API. I am curious as to what the reasoning was here? Also, it is hardly in the open community spirit to tell people to "come up with a better API" and then follow that with doubt that it will be useful. > > Surely good reasons where discussed with the community before > > deprecating the API, but I didn't find public discussion. If I missed > > it, please just give me the link ;-) > > I seem to have lost the memo requiring public discussion with the > community for a maintainership decision. probably my bad. can you point > me to it? Again, I think this is quite uncalled for. All Xavier is asking for is possible evidence that this was discussed openly. If that doesn't exist, then it only takes a moment to be polite and say so. Being sarcastic is really not professional and I am quite tired of this rhetoric. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
On Mon, 28 Jun 2010 14:49:48 +0100 Emmanuele Bassi wrote: > the fact that nobody implemented them using GCompletion should give a > hint that: a) this is not a shared opinion and b) it probably wasn't > possible with GCompletion. That's not quite true, several applications use GCompletion, just to mention some, Bluefish, Anjuta, Claws Mail. The issue isn't really about deprecating some code but instead not providing the alternative (look at QT for an idea, they always provided a compat library when it was necessary) This will be again the same picture as it has been with GTKCTree stuff: force application developers to waste time on changing something that actually just works and give room for new bugs while implementing the same functionality in a different way. I think it's a good practice to always provide compatibility and i'd like if GTK+ would do that too. regards, -- Salvatore ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
On Mon, 2010-06-28 at 17:58 +0200, Salvatore De Paolis wrote: > On Mon, 28 Jun 2010 14:49:48 +0100 > Emmanuele Bassi wrote: > > > the fact that nobody implemented them using GCompletion should give a > > hint that: a) this is not a shared opinion and b) it probably wasn't > > possible with GCompletion. > > That's not quite true, several applications use GCompletion, just to > mention some, Bluefish, Anjuta, Claws Mail. > > The issue isn't really about deprecating some code but instead not > providing the alternative (look at QT for an idea, they always provided > a compat library when it was necessary) > This will be again the same picture as it has been with GTKCTree stuff: > force application developers to waste time on changing something that > actually just works and give room for new bugs while implementing the > same functionality in a different way. and, again, there is this false impression that deprecation is akin to removal. this code is *not* going away. it's been marked as deprecated because nobody is actively maintaining it - and it hasn't been maintained for a while, now. the deprecation merely states the obvious: this code is not maintained and it should not be used in newly written applications because no guarantees can be made on its state. the code is not going to be removed until the next API bump - which, in GLib's case, is neither planned nor (at this point) wanted. you can either #undef G_DISABLE_DEPRECATED for the files that use these particular data structures, or copy gcompletion.[ch] in your project; since these files haven't been really changed in a while, the maintenance burden for projects is not heavy. > I think it's a good practice to always provide compatibility and i'd like > if GTK+ would do that too. the compatibility is all in the GLib API and ABI guarantees. since there are no plans on bumping them, the deprecated code will still be available. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Am Mon, 28 Jun 2010 17:28:47 +0100 schrieb Emmanuele Bassi : > On Mon, 2010-06-28 at 17:58 +0200, Salvatore De Paolis wrote: > > On Mon, 28 Jun 2010 14:49:48 +0100 > > Emmanuele Bassi wrote: > > > > The issue isn't really about deprecating some code but instead not > > providing the alternative (look at QT for an idea, they always > > provided a compat library when it was necessary) > > This will be again the same picture as it has been with GTKCTree > > stuff: force application developers to waste time on changing > > something that actually just works and give room for new bugs while > > implementing the same functionality in a different way. > > and, again, there is this false impression that deprecation is akin to > removal. > > [...] > > you can either #undef G_DISABLE_DEPRECATED for the files that use > these particular data structures, or copy gcompletion.[ch] in your > project; since these files haven't been really changed in a while, the > maintenance burden for projects is not heavy. One has to wonder where this "false impression" is coming from. Is it by any chance because there are loads of bugs and wiki pages about using G_DISABLE_FOOBAR and not relying on deprecated code? -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
On Mon, 2010-06-28 at 16:24 +0100, Martyn Russell wrote: > On Mon, 2010-06-28 at 14:49 +0100, Emmanuele Bassi wrote: > > On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote: > > > > > 1) I can think a bazillion of UIs that do/should have completion. > > > > the fact that nobody implemented them using GCompletion should give a > > hint that: a) this is not a shared opinion and b) it probably wasn't > > possible with GCompletion. > > You know this categorically? > > Under my own submission, the GtkEntryCompletion does cover most things I > ever needed. But I was quite surprised to read Xavier's email this > morning. I would have thought this was quite useful/used. Google code search returns a few legitimate users (as soon as you discount the apps copying glib in their own sources), many of which are old versions of existing applications. > > > Maybe > > > they can do that completion with something else than GCompletion, but > > > then the deprecation warning in the gtk-doc should point to that other > > > API. Probably GtkEntryCompletion is useful here, but can it be used with > > > editable GtkTextView (what empathy uses to write IM)? > > > > please, come up with a better API; since I very much doubt you can fix > > GCompletion to actually be useful for everyone, it would still require a > > deprecation of the GCompletion API. > > I am curious as to what the reasoning was here? a 2 minutes API review of GCompletion: • g_completion_new(): not bindable; requires at least a new version with a GDestroyNotify function for language bindings. • the GCompletionFunc doesn't have a data parameter, making it unbindable. • the GCompletion structure is completely exposed and cannot be extended or updated, hence we cannot add a GCompletionFuncData that takes a user data parameter, unless we use the struct alignment C trick, in which case the func pointers will be set to NULL even in valid cases. • the same applies for GCompletionStrncmpFunc. • the whole API uses untyped lists, which makes its use awkward from anything that's not C - and even in C it's odd to use, especially with regards to bookkeeping of the items. and this is just the API review - I didn't touch the implementation. honestly, I think this API was added too early in the GLib development cycle, without many users or a clear scope. the same could be said of GRelation, which has even fewer users. > Also, it is hardly in the open community spirit to tell people to "come > up with a better API" and then follow that with doubt that it will be > useful. that's not what I wrote. I wrote: | since I very much doubt you can fix GCompletion to actually be useful | for everyone, it would still require a deprecation of the GCompletion | API. I expressed doubts that you can effectively change GCompletion in an ABI/API compatible way; I honestly don't think it's possible without breaking some existing code. you can definitely write a new GCompletion API - and I very much encourage you to do so, if you wish, and propose it for inclusion after different applications used it. this would lead in any case to a deprecation of GCompletion as it is. > > > Surely good reasons where discussed with the community before > > > deprecating the API, but I didn't find public discussion. If I missed > > > it, please just give me the link ;-) > > > > I seem to have lost the memo requiring public discussion with the > > community for a maintainership decision. probably my bad. can you point > > me to it? > > Again, I think this is quite uncalled for. really? after: | 2) If all unmaintained code should be deprecated with no replacement, | what do we have left in glib/gtk? Probably not that much... I say it was perfectly called for. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
On Mon, 28 Jun 2010 15:26:47 +0200 Xavier Claessens wrote: > 1) I can think a bazillion of UIs that do/should have completion. Personally, I'd find GNOME-Do style "completion" totally awesome [1]. I don't know if it's feasible to have something like that at a low level in the stack, but the thought of a consistently do-ifyed entry experience in my GTK+-based desktop is very appealing. Just a thought, in case somebody wants to start a "cooler-GCompletion-replacement" discussion. Holger [1] For those that don't know GNOME Do: Their completions can cope with typing that doesn't start at the target strings, has gaps in it, and "learns" in a history-based fashion. It's basically an astonishingly well working "type 2 or 3 letters that come to your mind first and you got your answer" type of thing. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
On Mon, 2010-06-28 at 18:43 +0200, Christian Dywan wrote: > > and, again, there is this false impression that deprecation is akin to > > removal. > > > > [...] > > > > you can either #undef G_DISABLE_DEPRECATED for the files that use > > these particular data structures, or copy gcompletion.[ch] in your > > project; since these files haven't been really changed in a while, the > > maintenance burden for projects is not heavy. > > One has to wonder where this "false impression" is coming from. Is it > by any chance because there are loads of bugs and wiki pages about > using G_DISABLE_FOOBAR and not relying on deprecated code? it's a maintainer's choice to make your application rely on deprecated code; all the bugs and wiki pages in the world are there in an informational capacity only: I cannot get on your repository and just rip code out of your application. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why is GCompletion deprecated
>From and outsiders perspective I too would absolutely LOVE this feature. Not just in GTK, but in OS X as well. the OS X NSSearchField however (to my shock!) does not implement this functionality either. Apple has exposed this in the NSTextView (with spell check et al...) which is akin to GTKTextView. I suppose one could create a single line text view. In any case it seems like this would be a GREAT end user tool to be included in an application. I am surprised to read there is not that much use of it. As for the word deprecated (http://en.wikipedia.org/wiki/Deprecated) when I see this word anywhere it makes me RUN. I know that sooner or later that feature is NOT going to be there no matter how much I want it to be. So I can certainly (as a user of the library) understand why one would assume that deprecated also means DON'T work on it any more. I try to choose long lived objects, could it be that its use has been limited by placing a status of deprecated on it? My users are constantly looking up customer information. I want to give the CEO a tool by which he can pull up snapshots of customers by simply put in a word like "color" in the text field, and have all possible customers with that word "color" in their name appear. This seems to me like a must have for people at his level as they have 0 typing skills, and do not know any of the customer account numbers, and since 99% of all business do deal with some number of customers, and invariably have CEO who still pigeon pick at the keyboard, this type of functionality is not just useful, but gets us big pats on the back. At the end of the day, I can certainly do it "programmaticly", but is the point of a library NOT to have to app developers re-writing the same type of code? Of course this is beyond what is offered on the base platforms themselves. Thanks for reading my rant, Shawn > Subject: Re: Why is GCompletion deprecated > From: eba...@gmail.com > To: gtk-devel-list@gnome.org > Date: Mon, 28 Jun 2010 17:59:47 +0100 > > On Mon, 2010-06-28 at 18:43 +0200, Christian Dywan wrote: > > > > and, again, there is this false impression that deprecation is akin to > > > removal. > > > > > > [...] > > > > > > you can either #undef G_DISABLE_DEPRECATED for the files that use > > > these particular data structures, or copy gcompletion.[ch] in your > > > project; since these files haven't been really changed in a while, the > > > maintenance burden for projects is not heavy. > > > > One has to wonder where this "false impression" is coming from. Is it > > by any chance because there are loads of bugs and wiki pages about > > using G_DISABLE_FOOBAR and not relying on deprecated code? > > it's a maintainer's choice to make your application rely on deprecated > code; all the bugs and wiki pages in the world are there in an > informational capacity only: I cannot get on your repository and just > rip code out of your application. > > ciao, > Emmanuele. > > -- > W: http://www.emmanuelebassi.name > B: http://blogs.gnome.org/ebassi > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Le 28/06/10 15:48, Bastien Nocera a écrit : On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote: 2) If all unmaintained code should be deprecated with no replacement, what do we have left in glib/gtk? Probably not that much... That sort of comments has no place here, and hardly helps people feel any sympathy for your current conundrum. Sorry if you feel offended. What I mean is that gtk/glib has plenty of code that never get modified. That doesn't mean it's bad, just that code works and doesn't need to be actively maintained. For GCompletion and any other code in glib/gtk, surely if someone has an issue and propose a patch, maintainers will merge it. So my point is why is GCompletion less maintained that anything else in glib/gtk? Maybe unmaintained means it just work and everyone is happy with it... Unless we have real issue and nobody cared to fix them, which was my next point, and in that case I wanted to know more about the issues maintainers have with GCompletion. Regards, Xavier Claessens. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Le 28/06/10 15:49, Emmanuele Bassi a écrit : On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote: 1) I can think a bazillion of UIs that do/should have completion. the fact that nobody implemented them using GCompletion should give a hint that: a) this is not a shared opinion and b) it probably wasn't possible with GCompletion. Some application do use GCompletion, and empathy does... And it is working fine AFAIK. Maybe they can do that completion with something else than GCompletion, but then the deprecation warning in the gtk-doc should point to that other API. Probably GtkEntryCompletion is useful here, but can it be used with editable GtkTextView (what empathy uses to write IM)? please, come up with a better API; since I very much doubt you can fix GCompletion to actually be useful for everyone, it would still require a deprecation of the GCompletion API. How could I come up with a better API if: 1) You don't tell what's wrong with current? 2) You keep repeating completion is not used by app, and barely used code shouldn't be included in GLib? If that was true, even a better API should be rejected in glib... or is there something I didn't understand? 2) If all unmaintained code should be deprecated with no replacement, what do we have left in glib/gtk? Probably not that much... that is patently an hyperbole, and it's patently untrue. the deprecated code has been dropped from gtk+ 3.x and we still have a huge API footprint. How is this related to gtk+ api/abi break? Surely good reasons where discussed with the community before deprecating the API, but I didn't find public discussion. If I missed it, please just give me the link ;-) I seem to have lost the memo requiring public discussion with the community for a maintainership decision. probably my bad. can you point me to it? Do you mean you could remove, for example GtkTreeView, without telling anyone first, with no reason at all, if you wanted? GLib is community project and I though decisions could be taken in an open manner. Especially if that affect a few other GNOME applications, like empathy. I'm not saying I'm against deprecating GCompletion, but I just wanted to know what are the reasons. And as developer of an app that use GCompletion, what should I do now? If there are known big issues with GCompletion, surely empathy can get better in using something else, or even if we write new API and include it later in glib. But for that I need to know what are the issues in GCompletion to not be doing the same errors again. Regards, Xavier Claessens. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Le lundi 28 juin 2010 à 21:25 +0200, Xavier Claessens a écrit : > How could I come up with a better API if: > 1) You don't tell what's wrong with current? > 2) You keep repeating completion is not used by app, and barely used > code shouldn't be included in GLib? If that was true, even a better API > should be rejected in glib... or is there something I didn't understand? I think Emmanuele already listed the main issues with the current API: > • g_completion_new(): not bindable; requires at least a new version > with a GDestroyNotify function for language bindings. > > • the GCompletionFunc doesn't have a data parameter, making it > unbindable. > > • the GCompletion structure is completely exposed and cannot be > extended or updated, hence we cannot add a GCompletionFuncData that > takes a user data parameter, unless we use the struct alignment C > trick, > in which case the func pointers will be set to NULL even in valid > cases. > > • the same applies for GCompletionStrncmpFunc. > > • the whole API uses untyped lists, which makes its use awkward from > anything that's not C - and even in C it's odd to use, especially with > regards to bookkeeping of the items. So basically one would have to suggest an API more in key with the current conventions and bindings-friendly. What about providing something mixing search and completion from your GtkLiveSearch proposal? These features are deeply related with e.g. the advanced ways of searching (à la GNOME Do), allowing completion from different parts of a string, the beginning of any word, escaping accented characters... The new API should be usable alone, or automatically tied to a couple GtkEntry/GtkTreeView, so that only one completion API exists in GLib/GTK. Just my 2c ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Le 28/06/10 18:46, Emmanuele Bassi a écrit : a 2 minutes API review of GCompletion: • g_completion_new(): not bindable; requires at least a new version with a GDestroyNotify function for language bindings. • the GCompletionFunc doesn't have a data parameter, making it unbindable. • the GCompletion structure is completely exposed and cannot be extended or updated, hence we cannot add a GCompletionFuncData that takes a user data parameter, unless we use the struct alignment C trick, in which case the func pointers will be set to NULL even in valid cases. • the same applies for GCompletionStrncmpFunc. • the whole API uses untyped lists, which makes its use awkward from anything that's not C - and even in C it's odd to use, especially with regards to bookkeeping of the items. and this is just the API review - I didn't touch the implementation. honestly, I think this API was added too early in the GLib development cycle, without many users or a clear scope. the same could be said of GRelation, which has even fewer users. Great, this is what I was asking for. I didn't know about this :-) If those are the only issues, looks pretty trivial to deprecated GCompletion, and create a new API that don't have those issues. Maybe if there were a public call for help to fix those issues, we could have a replacement by now. Or did I missed an email where this was explained? If you think about other issues, please don't forget to tell us. Also, it is hardly in the open community spirit to tell people to "come up with a better API" and then follow that with doubt that it will be useful. that's not what I wrote. I wrote: | since I very much doubt you can fix GCompletion to actually be useful | for everyone, it would still require a deprecation of the GCompletion | API. I expressed doubts that you can effectively change GCompletion in an ABI/API compatible way; I honestly don't think it's possible without breaking some existing code. you can definitely write a new GCompletion API - and I very much encourage you to do so, if you wish, and propose it for inclusion after different applications used it. this would lead in any case to a deprecation of GCompletion as it is. I totally agree. I'm not against deprecating GCompletion, just needed to know what is needed to bring back that feature in GLib ;-) Surely good reasons where discussed with the community before deprecating the API, but I didn't find public discussion. If I missed it, please just give me the link ;-) I seem to have lost the memo requiring public discussion with the community for a maintainership decision. probably my bad. can you point me to it? Again, I think this is quite uncalled for. really? after: | 2) If all unmaintained code should be deprecated with no replacement, | what do we have left in glib/gtk? Probably not that much... I say it was perfectly called for. Didn't meant to be rude, sorry. I explained in another email what I meant. Regards, Xavier Claessens. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Am Mon, 28 Jun 2010 17:59:47 +0100 schrieb Emmanuele Bassi : > On Mon, 2010-06-28 at 18:43 +0200, Christian Dywan wrote: > > > > and, again, there is this false impression that deprecation is > > > akin to removal. > > > > > > [...] > > > > > > you can either #undef G_DISABLE_DEPRECATED for the files that use > > > these particular data structures, or copy gcompletion.[ch] in your > > > project; since these files haven't been really changed in a > > > while, the maintenance burden for projects is not heavy. > > > > One has to wonder where this "false impression" is coming from. Is > > it by any chance because there are loads of bugs and wiki pages > > about using G_DISABLE_FOOBAR and not relying on deprecated code? > > it's a maintainer's choice to make your application rely on deprecated > code; all the bugs and wiki pages in the world are there in an > informational capacity only: I cannot get on your repository and just > rip code out of your application. That is irrelevant. You expressed surprise that developers think they are highly encouraged to avoid deprecated code and do their best to keep building without it. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
