Re: Migration to GitLab, turn your notif off to avoid mail flood

[Morten Welinder]

> Just wanted to add that cut-and-paste is pretty freeform on Bugzilla.

Fair enough.  That somewhere between a blessing (if you cut and paste a
lot) and a problem (if you need to programmatically make sense of it).

Someone edited that particular bug, btw.  Anyone looking now might wonder
what the problem is.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Migration to GitLab, turn your notif off to avoid mail flood

[Morten Welinder]

It is just me, or is the migration mangling bugs?

Compare https://bugzilla.gnome.org/show_bug.cgi?id=765921
to https://gitlab.gnome.org/GNOME/gtk/issues/621

In bugzilla, the cut-and-paste compile commands with output are readable.
In gitlab, they're a mess.

Morten





On Tue, May 1, 2018 at 4:08 AM Carlos Soriano  wrote:

> Hello,

> Tomorrow Wednesday 2nd we're going to do the bug migration of gtk+. Since
gtk+ has been for some time in GitLab, probably most of you are subscribed
to notifications.

> This is a call to turn them off if you want to avoid your mail client
flooded. To do so, in the project overview click the bell and select none.

> I'll send an email here when migration is completed so you can turn it on
again.

> Best,
> Carlos Soriano
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Morten Welinder]

> Your behaviour on this mailing list, and on Bugzilla, has been
> consistently rude, inconsiderate, and plain abusive of the patience
> and effort that volunteers put in the platform you're consuming.

You have absolutely no respect for the work of other volunteers to the gtk+
project or for people whose opinions aren't aligned with you.  You put a high
value on your own disruptive work, and a value of zero on anyone else.

So, yeah, I don't like you.  And you probably don't like me.

Morten








On Mon, Feb 5, 2018 at 9:15 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
> On 5 February 2018 at 13:19, Morten Welinder <mort...@gnome.org> wrote:
>>> Considering that you usually stop short of the first step I have to
>>> ask you: what kind of "busywork" have you ever experienced?
>>
>> Here's a sample:
>> https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7
>>
>> Yes, that was you.  What did you really gain from asking that
>> question, other than verifying that I read my email?
>
> I gained the fact that you read your email and if you're still
> experiencing the issue, or if it was accidentally fixed in the ~4
> years between your original report and me going through the open bugs
> of gobject-introspection. That's why it was marked as NEEDINFO.
>
> As soon as you replied, the bug was reinstated as NEW and will be
> migrated to the gobject-introspection repository on gitlab.gnome.org.
>
>> The more typical sample -- not recently practiced by gtk+ -- is mass
>> moving of bugs into NEEDINFO with a note saying something like
>> "This bug was reported for version x.y. Please test if it still applies.  If
>> we get no response, this bug will be closed in 30 days."
>
> Which is what Matthias has said we're going to do in the email you
> replied to — and it's also implied in the NEEDINFO state as it's used
> by GNOME projects.
>
>> The reason I call that busywork is that you can actually do as asked
>> only to repeat the whole thing in a year when no-one has looked at
>> in the meantime.  And repeat it a year after that.  And multiply all that
>> by the number of open bugs you have.
>
> Oh, I'm sorry you're *so* inconvenienced by volunteers trying to get
> the bug count under control, and cannot replicate every single set up
> from 5 years ago.
>
>> Quite frankly, the rational response to such periodic requests is to
>> simply answer "the bug is still there" without going through the work
>> of checking.
>
> So, you're basically just making shit up?
>
> That's *really* great to know, because now I won't feel compelled at
> all to act on bug reports coming from you.
>
> Next time, either don't bother, or just be a decent human being, and
> answer "I don't know".
>
>>  That's rational for the bug reporter because it preserves
>> the investment of time that was put into reporting the bug without
>> spending more maintaining an large portfolio of open bugs.
>
> That's the "rational" thing to do if you're just abusing the ecosystem
> you're taking advantage of.
>
> Again, that's a great thing to know.
>
>>> Of course it is, that's why we generally don't do that — except,
>>> maybe, for rude bug reporters.
>>
>> You really don't like to be called out, do you?  (And, yes, I know I am
>> occasionally and deliberately rude.  The email you responded to was
>> not rude; it's just that you don't take criticism well, if at all.)
>
> Your behaviour on this mailing list, and on Bugzilla, has been
> consistently rude, inconsiderate, and plain abusive of the patience
> and effort that volunteers put in the platform you're consuming.
>
> You've been called out before, multiple times, about this.
>
> Of course, you can now spin it the way you want it, and say it's me
> that doesn't like being called out. I'll just remember it for the next
> time you open a bug, explaining what *I* have to do, without even
> bothering to attach a patch. Or reply "this bug still exists" without
> testing it, because you're too busy with your own stuff.
>
> Ciao,
>  Emmanuele.
>
>> On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
>>> On 4 February 2018 at 20:52, Morten Welinder <mort...@gnome.org> wrote:
>>>> As a general principle, you should only ask bug reporters to do work if you
>>>> intend to do something with the answer.  Or, with other words, it really is
>>>> not nice to keep asking "is that bug still there?" until they get tired of 
>>>> the
>>>> busywork and leave in disgust.
>>>
>>> T

Re: migrating gtk

[Morten Welinder]

> Considering that you usually stop short of the first step I have to
> ask you: what kind of "busywork" have you ever experienced?

Here's a sample:
https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7

Yes, that was you.  What did you really gain from asking that
question, other than verifying that I read my email?

The more typical sample -- not recently practiced by gtk+ -- is mass
moving of bugs into NEEDINFO with a note saying something like
"This bug was reported for version x.y. Please test if it still applies.  If
we get no response, this bug will be closed in 30 days."

The reason I call that busywork is that you can actually do as asked
only to repeat the whole thing in a year when no-one has looked at
in the meantime.  And repeat it a year after that.  And multiply all that
by the number of open bugs you have.

Quite frankly, the rational response to such periodic requests is to
simply answer "the bug is still there" without going through the work
of checking.  That's rational for the bug reporter because it preserves
the investment of time that was put into reporting the bug without
spending more maintaining an large portfolio of open bugs.

I understand that there can be a desire to close bugs unfixed.  What I
object to is sending them through NEEDINFO and then ignoring them.
That route should be reserved for bugs you intend to work on as soon
as the requested info arrives and for cases where you believe the bug
is actually fixed, but just want confirmation from the reporter.

> Of course it is, that's why we generally don't do that — except,
> maybe, for rude bug reporters.

You really don't like to be called out, do you?  (And, yes, I know I am
occasionally and deliberately rude.  The email you responded to was
not rude; it's just that you don't take criticism well, if at all.)

I hope we can agree that bug reporters are volunteer contributors to
the project and that they should be treated with respect.

Morten








On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
> On 4 February 2018 at 20:52, Morten Welinder <mort...@gnome.org> wrote:
>> As a general principle, you should only ask bug reporters to do work if you
>> intend to do something with the answer.  Or, with other words, it really is
>> not nice to keep asking "is that bug still there?" until they get tired of 
>> the
>> busywork and leave in disgust.
>
> The busywork meaning "attaching a patch and iterating over it"?
> Considering that you usually stop short of the first step I have to
> ask you: what kind of "busywork" have you ever experienced?
>
> Of course if we get a positive response that the bug is still there
> we're going to migrate it and keep track of it.
>
>> With that in mind, I believe it is much nicer to just leave the old bugs 
>> there.
>
> The old bugs will be left there, but closed, so we don't need to check
> two bug lists, and split the maintenance resources even more.
>
>> We never got around to solving the reporter's problem, but at least we did
>> not add to the pain by asking them to do work and report back, only to
>> ignore the result of that.  Doing that is quite rude.
>
> Of course it is, that's why we generally don't do that — except,
> maybe, for rude bug reporters.
>
> Ciao,
>  Emmanuele.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Morten Welinder]

As a general principle, you should only ask bug reporters to do work if you
intend to do something with the answer.  Or, with other words, it really is
not nice to keep asking "is that bug still there?" until they get tired of the
busywork and leave in disgust.

With that in mind, I believe it is much nicer to just leave the old bugs there.
We never got around to solving the reporter's problem, but at least we did
not add to the pain by asking them to do work and report back, only to
ignore the result of that.  Doing that is quite rude.

Morten








On Fri, Feb 2, 2018 at 9:04 AM, Matthias Clasen
 wrote:
> Hey Carlos,
>
> we discussed gitlab migration for gtk here at the hackfest. Our conclusions
> were as follows:
>
> * We want to migrate the git repository as soon as possible
> * For bugs:
>   * Do a sweep now, close all >5 year old bugs, needinfo all >1 old ones
>   * Wait a few weeks, then close the needinfoed bugs that didn't get a
> response
>   * Triage the rest
>   * Migrate what's left at the end
>
> Does this sound plausible to you ?
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Morten Welinder]

You're right.  On re-reading that I find that it came out harsher than
it ought to have.  My apologies.

Morten


On Thu, Apr 20, 2017 at 7:14 AM, Emmanuele Bassi <eba...@gmail.com> wrote:
> On 19 April 2017 at 13:29, Morten Welinder <mort...@gnome.org> wrote:
>
>> glib (etc) _is_ stomping on the standard in a hundred different ways.  Some
>> are for performance -- \0 filling, for example -- while others are pure 
>> laziness
>> and ignorance such as variables called "read" or macros name starting with 
>> "E".
>
> Morten, I know you have had your issues with the GTK developers, but
> I'd appreciate it if you refrained from telling people they are "lazy
> and ignorant". This is not the first time you're treading the needle
> of outright insulting people in the GTK community.
>
> I'd like to remind everyone (myself included) that the GTK development
> mailing list operates under the same Code of Conduct of the GNOME
> Foundation as any other service provided by the GNOME infrastructure.
> It's important that all the discussion venues are kept civil and
> welcoming places for everyone.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Morten Welinder]

You are making the situation sound a bit worse than it actually is.

> Not relying on aliasing forbids casting between dissimilar types, which
> rules out "normal" C tricks like casting between GArray and GRealArray
> (where GRealArray starts with the same members as GArray) as a way to have
> a partially-opaque struct, or an opaque-other-than-size struct on the stack;
> so regardless of whether it might be desirable to be writing Standard
> C, I'm not sure that GLib can do that without breaking its API.

C99 can do that, although access needs to be via a union type.
C99 section 6.5.2.2 #5.  No API break would be need to do it.


> whether the usual C pseudo-object-orientation idiom[1] (which
> is a fairly fundamental part of GObject) is considered to be valid in
> Standard C

That works fine.  C99 section 6.7.2.1 #12.

glib (etc) _is_ stomping on the standard in a hundred different ways.  Some
are for performance -- \0 filling, for example -- while others are pure laziness
and ignorance such as variables called "read" or macros name starting with "E".

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'

[Morten Welinder]

> Currently, there are 2 rounding functions in the fall backs, round()
> and rint(), with rint() having the better less biased IEEE
> round-to-even behavior for the 0.5 case.

Is known and it is a problem that the fallbacks for round and rint
are only mostly working?

For example, there is a number strictly less than 0.5 that round will
round to 1.  And there are a large number of large integers that
round will change.

Morten





On Sat, Feb 4, 2017 at 10:59 PM, Yale Zhang  wrote:
> I suggest adding a lrintf() fallback to fallback-c89.c too.
>
> Currently, there are 2 rounding functions in the fall backs, round()
> and rint(), with rint() having the better less biased IEEE
> round-to-even behavior for the 0.5 case.
>
> lrintf() is preferable because it can be done in a single instruction
> (round and convert to int) on x86, while (int)round(x) would need 2
> instructions.
>
> I suggest the following implementation of lrintf():
>
> inline int lrintf(float x)
> {
> // warning: assumes processor's rounding mode is set to nearest int
> #if defined(__SSE__) && defined(__GNUC__)
> // single instruction version that avoids conversion of float to SSE 
> vector
> int rounded;
> __asm__ (
>  "cvtss2si %1, %0\n"  // most compilers are smart enough
> to convert this to vcvtss2si to avoid expensive AVX-SSE transition
> penalties
>  : "=r"(rounded)
>  : "x"(x)
> );
> return rounded;
> #elif defined(__SSE__)
> return _mm_cvtss_si32(_mm_set_ss(x));
> #else
> return rintf(x);
> #endif
> }
>
>
> On Sat, Feb 4, 2017 at 12:17 PM, John Emmas via gtk-devel-list
>  wrote:
>> On 4 Feb 2017, at 19:44, Emmanuele Bassi wrote:
>>
>>>
>>> Please, file a bug against gdk-pixbuf:
>>>
>>>  https://bugzilla.gnome.org/enter_bug.cgi?product=gdk-pixbuf
>>>
>>> I'd rather have a check at configure-time that looks if we have
>>> lrint() available, and if not, provides a fallback. We used this
>>> approach in GTK+ 3.x, and it makes it easier to remove the code once
>>> we decide to bump the compiler requirements, like we did in GTK+
>>> master.
>>>
>>
>> Thanks Emmanuele - just filed bug #778181
>>
>> John
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Morten Welinder]

> When GTK+ breaks the API, it doesn't mean that a higher-level library
> needs to break API too.

That depends.

You are right that a lot of API changes can be hidden.

But if the higher-level library has an API  that includes a type
which is being removed, then the API will have to be
changed.

And if your library depends on a feature that is being removed
then your library probably cannot be saved with an API break.

M
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Does Gtk+ Still Support Application-Provided Widgets?

[Morten Welinder]

Gtk+ used to support custom widgets.  Whenever you were unhappy with
the official
set you would hack up your own.  More often than not, this would start
by copying
an official widget's code and do a mass rename of identifiers.

No more.

More and more of the api needed to created widgets is migrated into
gtk*private.h
headers rendering it inaccessible for applications.  Take GtkButton,
for example.
It includes the following private headers:

#include "gtkbuttonprivate.h"
Just a structure, but it is included also outside gtkbutton.c.  I.e.,
widgets like GtkCheckButton
are allowed special privileges that MyButton is not.

#include "gtkwidgetprivate.h"
Again, there really should not be any API that in-tree widgets are
allowed to use, but
out-of-tree widgets are not.  I can see a case for
"gtkwidgetprotected.h" in the C++ sense,
though.

#include "gtkprivate.h"
No idea.

#include "gtkapplicationprivate.h"
I don't think this one is actually used.

#include "gtkcsscustomgadgetprivate.h"
The whole gadget machinery is private.  Anyone who wants stateful css
nodes gets to
implement the whole css stack themselves.

#include "gtkcontainerprivate.h"
This is just silly.  Either something is useful for containers in
general and it should be public, or
else it is not useful and it should go into gtkcontainer.c

Suggestion:  Only gtkbutton.c should be allowed to include
gtkbuttonprivate.h and similarly
with other private headers.  Create gtkbuttonprotected.h if needed and
install it.  Add needed
API for derivation either to gtkbutton.h or gtkbuttonprotected.h.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: File monitor rewrite: Solaris (and other) help wanted

[Morten Welinder]

 My plan is to make it a guarantee of the API that both CREATED
 and CHANGED events will always be followed by a CHANGES_DONE
 hint.

Great plan, but you cannot get that in a meaningful way.  Think

creat
write
mmap
close
# Further writes by way of the mapped region

I don't think you can detect the end of that write.

Morten








On Thu, Jan 15, 2015 at 10:42 AM, Ryan Lortie de...@desrt.ca wrote:
 hi Aleksander,

 On Thu, Jan 15, 2015, at 06:28, Aleksander Morgado wrote:
 Currently GFileMonitor doesn't have a unique way to know whether a file
 got closed. There is the changes-done-hint event, but that covers IIRC 2
 things: files getting closed and also a virtual emission which happens
 after some time even if the files were not closed (think of a log file
 which never gets closed). The main issue is that if you want to get
 notified of when a file was fully updated *and* closed, you need to
 fallback to raw inotify. The rationale for wanting to get notified only
 when the file got closed is e.g. Tracker monitoring the Downloads/
 directory. We may not want to extract file info for an ongoing download,
 just for when the download is fully finished (and destination file
 closed). More background here:
 https://bugzilla.gnome.org/show_bug.cgi?id=635765

 Short story: I want to add a flag to either disable or enable emission
 of virtual changes-done hints on monitor backends that can reliably
 handle it themselves.

 Even for fully-capable backends, I think virtual emissions are
 potentially important because, even if the file is not closed, someone
 watching it may want to update their opinion of its contents
 periodically.  The question is only about what the default should be.
 Those who favour a nice clean API would say that virtual emissions
 should be off by default.  Those who favour backwards compatibility
 would suggest that today's behaviour of virtual emissions should be kept
 as-is unless explicitly disabled.  I'm not sure what we will do.

 Unfortunately, there's a longer story: None of the backends support
 reliable emission of non-virtual changes-done.

 Here's why:

 My plan is to make it a guarantee of the API that both CREATED and
 CHANGED events will always be followed by a CHANGES_DONE hint.  That's
 already enforced in the state machine logic in GFileMonitorSource in the
 branch.  My reason for that is that apps like Tracker should not want to
 response to CREATED events until the file content is complete.

 The idea (taking your download example) is that a file is created
 something like so:

   creat()
   write()
   write()
   close()

 which sends us IN_CREATE, IN_MODIFY, IN_MODIFY, IN_CLOSE_WRITE.

 As you mention, it doesn't make sense for the app to respond to the
 empty (or maybe very slightly populated) download just because it saw a
 CREATED event from GFileMonitor -- it should wait for the CHANGES_DONE.
 Consider this case:

   creat()
   close()

 in that case, we'd see IN_CREATE, IN_CLOSE_WRITE, with no IN_MODIFY.  We
 still want to see a CHANGES_DONE event in that case, though so that the
 app knows that the empty file is the 'final result'.  This is the basis
 of my opinion that CREATED should always get a CHANGES_DONE after it,
 even without actual CHANGED events.

 With the new support for move and rename events, a file created by the
 write to temp and mv into place method will be reported either as
 MOVED_IN or RENAMED with no CHANGES_DONE.  That's okay, because you know
 that a file that was MOVED_IN or RENAMED into place is ready to be
 handled immediately.

 Unfortunately, there is another set of cases.  IN_CREATE is sent both
 for the creat() case (in which case it will be followed by
 IN_CLOSE_WRITE) but also for cases like mknod(), bind() on a unix
 socket, mkdir(), etc..  In those cases, we will receive no
 IN_CLOSE_WRITE.  We could detect that situation by looking at the
 filesystem and seeing that the newly-created file is of a special type,
 but link() also produces IN_CREATE without IN_CLOSE_WRITE.

 The only thing that saves us in this second case is that we get a
 virtual emission of CHANGES_DONE a couple of seconds later.  At least
 link() is uncommon, although it stands to become a more common way of
 creating files, via O_TMPFILE.

 In short, I believe that we currently don't have any backend for which
 we could safely disable emission of virtual CHANGES_DONE events.
 Ideally, in the future, we will gain a mechanism in inotify to tell the
 difference between file created via open for writing, IN_CLOSE_WRITE
 coming soon and inode appeared in the file system in complete form.
 At that point we could expose a new event type in GFileMonitor
 (_APPEARED?) that doesn't need CHANGES_DONE to be emitted.

 Cheers
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list 

Re: File monitor rewrite: Solaris (and other) help wanted

[Morten Welinder]

That does leave tracker-like software in a bad position.

Although I guess one could lobby the kernel people for an inotify
event when a file is mapped and use it as a kind of a hint that the
file should be revisited at some later point.

Morten





On Thu, Jan 15, 2015 at 10:51 AM, Ryan Lortie de...@desrt.ca wrote:
 hi,

 On Thu, Jan 15, 2015, at 10:49, Morten Welinder wrote:
 Great plan, but you cannot get that in a meaningful way.  Think

 creat
 write
 mmap
 close
 # Further writes by way of the mapped region

 I don't think you can detect the end of that write.


 Quoting inotify(7):

The inotify API does not report file accesses and modifications
that may
occur because of  mmap(2),  msync(2), and munmap(2).

 so this is a completely lost cause anyway.

 Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Morten Welinder]

This is the third (fourth) incarnation of a combo box and there is
still opposition to keeping the API stable?  That's just crazy.
Matthias' awesomeness aside, why would this be the last time?

Seriously, a change in a widget like this means 20+ hours[*] of
extra work for me as an application writer.  I have a lot of GUI
to deal with, but say 10 hours is the average and look at 100
applications.  1000 hours of work that doesn't advance the
functionality of the applications.

If it took Matthias an extra 500 hours -- something like three
months of his time -- it would still be better to use the old api.
Or at least some variant for which the changes would be
doable by search-and-replace.

Morten



[*] That's probably a low estimate.  It not just finding all uses of the
old and replacing with the new.  It's debugging the application
_and_ the new widget; filing bugs against the widget; writing
work-arounds for the 2 years before fixes are made and distributed;
it's tracking the API changes that are a consequence because a
non-gtk library function that is based on the widget will now have
new signals being fired -- no help from the compiler there.


On Sun, Dec 28, 2014 at 9:07 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 On Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz ar...@gnome.org wrote:
 My main concern with the design is that users can't make a difference
 between a normal button and this widget (usually related to an action,
 perhaps with the exception of iconized menus like the ones we're using in
 headerbars these days).

 Is there any design rationale to remove the usual arrow?

 You should try the actual thing... I had the same question, and added
 the arrow back
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Morten Welinder]

 on the contrary: with a new class you'd be sure that the GtkComboBox
 widget API is finally stable — as in no changes, except for bug
 fixes — which is apparently what you want.

There are three types of widgets in the gtk+ world: (1) active and
non-deprecated, (2) deprecated, and (3) deprecated and removed.

Application writers know that (2) is on the way to (3), even if gtk+
developers like to publicly say that isn't true.  It's just that we have
never observed anything else.

So, no.  I don't want the API stability in (3).  And the bug fixes part
for (2) is by and large PR.  In the real world, it doesn't happen and
I am regularly reminded of this when 10 year old bug reports get
closed wontfix or obsolete.

Emmanuele, why are you so cavalier about inflicting pain and work
on application writers?

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Morten Welinder]

Can we keep the api -- function names, etc.?

I.e., could we, for once, do such an upgrade without inflicting
pain on the users?  Even at the cost of some pain for
developers.

Morten


On Sat, Dec 27, 2014 at 4:29 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom
 tris...@upstairslabs.com wrote:


 It's really not that bad, combobox is currently  6k lines of code which
 is really not much for all that it does, sure we could afford to do a
 bit less (like dropping the crazy tabular menus).

 Tbh, thats only true after your shoved off 2000+ lines to gtktreemenu.c.

 Honestly I would have rather proposed to just switch the whole internals
 of combobox to do the more modern looking thing using cell areas, which
 strikes me as the obvious way forward, bringing a new look to the combo
 without dropping any of the value of combobox, and every app using
 combobox automatically benefits - only that it would probably result in
 breaking API.

 Frankly I don't appreciate this let's rewrite everything from scratch
 attitude, it doesnt show a whole lot of respect to the users of our API,
 who would, I think have a justifiable expectation that their usage of
 combobox would not be labeled as obsolete at least until GTK+ 4.

 Sure, exceptions can be made within reason for dropping huge important
 parts of GTK+, but let's stick within reason right ? Has this been
 discussed ? Has it been concluded that there is no way forward with
 the existing API ? Where is that discussion ? What is the rationale ?

 Thats one of the hardest questions, isn't it ?

 Deciding when a codebase that you've invested a lot of time and effort
 into has grown too old and complex, and it is better to start from
 scratch ? I'm often struggling with this, and stick to fixing things
 up to 'preserve existing investment' far too long. Of course, starting
 over is not a panacea: you may end up repeating old mistakes, and do a
 lot of work just to end up in the same place you started from. On the
 flip side, its a chance to revisit old assumptions that are deeply
 embedded in the old code, add modern features without having to
 force-retrofit them into ancient code (and cause collateral damage in
 the process).

 That being said, I think the case for GtkComboBox is pretty clear-cut.
 It was doomed from the beginning by the mistake to force two pretty
 distinct user experiences (option menus and combo boxes) into a single
 widget. You've made a valiant attempt to clean this up with the
 introduction of GtkTreeMenu, but it is still a mess. Another mistake
 was to expose a data-driven API (with models and cell renderers) for a
 widget that most of the time is used in non-data-driven scenarios.
 We've later tried to patch up that mistake by adding the simplified
 GtkComboBoxText. But since it is a subclass, it inherits all of the
 api problems of GtkComboBox. Lastly, there's a number of ill-advised
 APIs in GtkComboBox that make it very hard to do any new
 implementation of the same api: tabular menus, spanning columns, etc.
 Almost as if to prove the last point, your last major refactoring of
 GtkComboBox already broke a bunch of those APIs (e.g. col-span-column
 is not working anymore).

 You'll be happy to learn that the buildable API of GtkCombo is
 pretty close to compatible with GtkComboBoxText (I should probably
 rename the active property to active-id to get even closer), so for
 most users, switching from GtkComboBoxText to GtkCombo should be as
 simple as s/GtkComboBoxText/GtkCombo/ in their ui files.

 Since you are asking about discussions and conclusion, I'll state that
 in my opinion, combo boxes should not use (even less expose in the
 api) cell renderers and tree models. I believe that is pretty much
 agreed upon between most people who regularly touch GTK+ code (with
 the exception of you, possibly).  Speak up if you disagree.
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: A Gtk's build system ?

[Morten Welinder]

I should hope not.

Autotools is indeed the worst possible solution, except for all the
others.  (With apologies to Churchill.)  But it exists and it is a
known quantity.

It solves problems like generation of tar balls, checking that the tar
balls actually
work, running test suites, checking translation completeness, handles cross-
compilation (to a point), multiple architectures, parallel builds,
etc.  Hard stuff.

(It also handles hardware last observed in the late 70s, but you
aren't harmed by
that.)

I really do not see a need to sink time into replacing all that.
Especially not if
the simplification consists of using the ostrich approach -- *I*
don't have that
problem so it is not important.

Re your specific concerns: linux, osx, win32 all have the unix tools;
there ought
to be a macro provided to find glib-compile-resources; with counceling you will
get over the ugliness.

Morten





On Tue, Aug 5, 2014 at 9:35 AM, Victor Aurélio Santos
victoraur.san...@gmail.com wrote:
 Hi folks,

 Is there a plan to write a new build system or use another existing
 build system for Gtk instead of Autotools ?

 I ask this because autotools is something not good enough for me.
 It's syntax is ugly and bad to remember, the platform that will run
 autotools requires a UNIX tool-set (sh, make, etc...), there's no
 support to glib's features like resources the developer have manually
 find the glib-compile-resources executable and write rules to build
 the resources, and so on.

 I also think that Gtk should have something Gtk's build system, Like
 Qt's qmake.

 If not, do anyone know if GNOME plan this ?
 Note that jhbuild is not a build system, it's more a build bot.

 Thanks, I'll be happy to hear your plans and pros/cons of move to
 another build system.
 --
 Victor Aurélio Santos
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Morten Welinder]

For the record, the use of gdk_cairo_create outside of a
begin_paint_region / end_paint pair also seems to work fine on win32.

Morten


On Mon, Jun 23, 2014 at 6:02 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
 Hey everyone again

 I wasn't expecting this much fallout from the change. I was hoping most of
 the GTK+ applications were only using widgets and draw signals. I was wrong.

 I've effectively pushed a revert of these changes:

 https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6
 https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf

 Note that gtk_widget_set_double_buffered is still deprecated, and calling
 gdk_cairo_create outside of a begin_paint_region / end_paint is still
 considered legacy and isn't guaranteed to work on any backends other than
 X11. Everything should be functioning correctly. So, we're choosing to make
 these things work for X11, but new backends like Wayland, Broadway and Mir
 might not work with them.

 If your application still has flickering or prints runtime warnings or
 crashes, *please* let me know. We should be back to where we were
 beforehand, but things do sometimes slip through the cracks.

 Thanks to everyone who gave me feedback -- it's been a frustrating past few
 days for everyone, and I'm sorry for the breakage I caused. I have a much
 better handle on the situation now and the way applications are using our
 toolkit.

 If you have any other feedback about modern drawing in GTK+, please let us
 know. We're always trying to support application developers, even if it may
 not seem like it, and if our existing APIs aren't suiting your use cases, we
 need to know.


 On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 To better support Wayland with fewer copies and less drawing artifacts,
 I've pushed some potentially breaking changes to GDK, namely around
 gdk_cairo_create and gdk_window_begin_paint_region.


 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848

 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e

 With these changes, it is now illegal to call gdk_cairo_create outside of
 a begin_paint / end_paint. This was always sketchy, and would never work on
 Wayland anyway. If your code does this, we will print a warning and return a
 dummy surface which won't ever be composited back into the main surface.

 Additionally, it is now forbidden to call gdk_window_begin_paint_region
 more than once. Previously, the code had a paint stack which tracked
 paints, but since GTK+ never used this codepath it was never actually tested
 and was indeed broken on Wayland due to the way the Wayland backend was
 written. Again, we will print a warning in this case and return.

 As part of these changes, gtk_widget_set_double_buffered was deprecated
 and removed. Again, it will never work on Wayland, as that is natively
 double-buffered, and it would simply break there.

 I tested with some local big applications like Ardour and the GNOME
 applications, but don't have a GTK+3 build of Firefox, LibreOffice, Eclipse,
 or any big GTK+ apps like Inkscape or The GIMP.

 Please double-check to make sure your apps still work fine. If you have a
 problem with any of this or I broke your apps by accident, please reply and
 I'll try to fix it.

 Thanks!

 --
   Jasper




 --
   Jasper

 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Morten Welinder]

Argh!

Will the stream of ABI changes never end?

Gnumeric uses this to provide a walking-ant cursor large selected areas -- areas
too big for processing in the normal paint loop.

Morten





On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
 To better support Wayland with fewer copies and less drawing artifacts, I've
 pushed some potentially breaking changes to GDK, namely around
 gdk_cairo_create and gdk_window_begin_paint_region.

 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e

 With these changes, it is now illegal to call gdk_cairo_create outside of a
 begin_paint / end_paint. This was always sketchy, and would never work on
 Wayland anyway. If your code does this, we will print a warning and return a
 dummy surface which won't ever be composited back into the main surface.

 Additionally, it is now forbidden to call gdk_window_begin_paint_region more
 than once. Previously, the code had a paint stack which tracked paints,
 but since GTK+ never used this codepath it was never actually tested and was
 indeed broken on Wayland due to the way the Wayland backend was written.
 Again, we will print a warning in this case and return.

 As part of these changes, gtk_widget_set_double_buffered was deprecated and
 removed. Again, it will never work on Wayland, as that is natively
 double-buffered, and it would simply break there.

 I tested with some local big applications like Ardour and the GNOME
 applications, but don't have a GTK+3 build of Firefox, LibreOffice, Eclipse,
 or any big GTK+ apps like Inkscape or The GIMP.

 Please double-check to make sure your apps still work fine. If you have a
 problem with any of this or I broke your apps by accident, please reply and
 I'll try to fix it.

 Thanks!

 --
   Jasper

 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLogLevelFlags enum and g_log

[Morten Welinder]

 enum GLogLevel {
... existing, expected values ...
_require_int = INT_MAX
 }


That actually makes the whole thing undefined rather than implementation
defined by section 7.1.3 in C99.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: symbolic icon fallback failure

[Morten Welinder]

 Actually - what's wrong with posix realpath() ?

In my case, not available.  And if the aim is portability, see BUGS
in the man page.

M.


On Mon, Nov 25, 2013 at 3:54 AM, Patrick Welche pr...@cam.ac.uk wrote:
 On Sun, Nov 24, 2013 at 08:31:21PM -0500, Morten Welinder wrote:
  rsvg-base.c:2194:5: error: implicit declaration of function 
  'canonicalize_file_name'

 This patch (used for Win32, but there isn't anything win32 specific in there)
 with minimal editing should get you going.


 https://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/librsvg-portability.patch

 Actually - what's wrong with posix realpath() ?

 Cheers,

 Patrick
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: symbolic icon fallback failure

[Morten Welinder]

 rsvg-base.c:2194:5: error: implicit declaration of function 
 'canonicalize_file_name'

This patch (used for Win32, but there isn't anything win32 specific in there)
with minimal editing should get you going.


https://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/librsvg-portability.patch

On Sun, Nov 24, 2013 at 8:04 PM, Patrick Welche pr...@cam.ac.uk wrote:
 On Sat, Nov 23, 2013 at 03:14:47PM -0500, Matthias Clasen wrote:
 On Sat, Nov 23, 2013 at 12:12 PM, Patrick Welche pr...@cam.ac.uk wrote:

  On Sat, Nov 23, 2013 at 04:04:08PM +0100, Milan Bouchet-Valat wrote:
   Just a random guess, but are you sure Gdk was built with SVG support
   enabled? You need librsvg, and sometimes it happens to be missing (or
   not found)
 
  That was what I was worried about in:
 
  https://mail.gnome.org/archives/gtk-list/2013-November/msg00015.html
 
  I have libpixbufloader-svg.so and an svg entry in loaders.cache.
 
  Given that there were no replies, I assume that that is the complete
  checklist.
 

 Your librsvg may be too old to render symbolic icons. See


 https://git.gnome.org/browse/librsvg/commit/?id=b864307868d3977dfa5e127ff95d7efded854850

 and the bug referenced there.

 Indeed: I am using librsvg 2.36.4 as per the referenced email. I just had
 a go at building 2.40.1, but:

 rsvg-base.c:2194:5: error: implicit declaration of function 
 'canonicalize_file_name'

 ?

 Cheers,

 Patrick
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Stock Items Deprecation

[Morten Welinder]

 Is there some way, as with GtkUIManager, to merge in, and later remove
 and replace, menu items? I used this with GtkUIManager to dynamically
 populate a menu with items not known at compile time.

Specifically, how does one create menus like Firefox's History and Bookmarks
menus which have dynamic contents?  Or gedit's Documents menu?

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: bugzilla cleanup

[Morten Welinder]

 It can be easily fixed in the sense that every application also would then
 need to be fixed...

Behdad, you're sitting in your ivory tower and throwing mud at
suggested patches from people who suffer from this bug.  What
is the point of that?  In the meantime, as Krzysztof points out,
GOption simply doesn't work on Win32.

I stand behind the original five-year old patch.  The biggest
complaint against that seems to be what to name one of
the functions.

Note, that there are other large parts of glib, such as gio, that
have basically don't work on win32.  And have five-year old
patches in bugzilla.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Function pointer casts

[Morten Welinder]

 This code casts GCompareFunc to GCompareDataFunc.  As I understand, casting
 function pointers in C is not allowed.

You're right, of course, but considering that the signal code
depends heavily on casting function pointers with no obvious
completely standard-sanctioned substitute, there's really
no reason to single out this particular cast.  In practice
it works just fine anyway where you are likely to get
glib/gobject to run anyway.

The same problem occurs in any code using dlsym, such
as GModule.  To use that you need to cast a data pointer to
a function pointer which isn't allowed (unless the thing you
cast is a null pointer constant and then it isn't really that
interesting).

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Guidelines for stable branch changes in GLib/Gtk

[Morten Welinder]

 If I'm not mistaken, this was a different kind of breakage that
 we engage in a lot of lately: API-incompatible changes on the
 unstable branch.

Close, but not quite.  This was a case of user updates gtk+ to new
stable 3.x and applications cease to work.  No API involved, it's all
a matter of ABI.

The normal mechanism to signal ABI changes is to admit it and change
soname.  However, that is so painful[*] that people get the urge to sneak
little changes in here and there.

Morten



[*] So painful that the g++ people backed out a change to std::list
required for standards compliance in order to avoid changing soname.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Guidelines for stable branch changes in GLib/Gtk

[Morten Welinder]

The breaking of mouse wheel support in gtk+ 3.4 also comes to mind.
(Bug 675089 and others, I'm sure.)

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: next steps for touch support in GTK+

[Morten Welinder]

On Sat, Aug 4, 2012 at 3:44 AM, Emmanuele Bassi eba...@gmail.com wrote:

 GtkSwitch bugs me.  It really should just have been a styling of the toggle
 button since it performs the same function with a different look.

 it does not perform the same action.

That is a baseless assertion.  Of course it does.
And stop misquoting me, please.

We're talking about two widgets that are both used
to turn something off or on.  And nothing else.
How is that not the same function?

In other words, is there a place where one of them
is used that would not function right if the other one
was substituted?


 as a side question: do you think that I, and everyone who reviewed
 that patch, is stupid and doesn't know about the existence of
 GtkButton?

Nope, I don't.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: next steps for touch support in GTK+

[Morten Welinder]

 === 4. Which GTK+ widgets break with touch ===
 The SpinButton item from above is one example of those.

I really hope the solution is neither remove anything that doesn't work
with touch or parallel widget hierarchy.

GtkSwitch bugs me.  It really should just have been a styling of the toggle
button since it performs the same function with a different look.  But no,
it is currently a totally separate widget not even derived from GtkButton.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gir stability

[Morten Welinder]

This seems like a minor issue compared to GtkGrid 3.0 vs GtkGrid 3.2
incompatibilities.  A could of attributes got swapped in-between those
two versions.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: How GTK styling works

[Morten Welinder]

 7) Ditch theme engines

I like it!  No more insanely weird bugs that eventually get
tracked down to a theme engine doing things wrong.
(Weird as in: the last thing people think of when, say,
floating-point numbers get truncated, is that the theme
has changed part of the locale.)

I hope you realize how big a job you are getting yourself into, :-)
Or that you have made sure you'll get properly paid.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Morten Welinder]

Will the new api allow one to write a gui that looks and feels
like it was made with the old api?

Thanks,

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObjectClass.dispose and bringing objects back to life

[Morten Welinder]

 What we probably also should do is deprecate one of the two
 virtual functions, so people use the same one to clean up everywhere.

That would be a _really_ bad idea.

_finalize gets rid of the last fragments of the object.  Since random
code could have obtained refs to the object, the object designer
can generally not control when this happens.

_dispose has two functions: (1) break reference cycles by getting
rid of as many objects as it can, and (2) getting rid of externally-
visible parts of the object and subobjects it owns.

(2) tells you why you can't merge the two methods.  Widgets,
for example, really need to go away from the screen when you
tell them, not whenever something else decides to release a ref.
Objects that have open files really need to close them at dispose
time, not next Wednesday.

Gtk1 didn't have dispose in name, but it had the destroy method
instead.  Same thing.

 [...] we [...] know that trying to support objects functioning
 after dispose is like trying to make your code handle
 NULL returns

I don't think we know that, not do I think it's true.

Making _dispose work really comes down to following one
simple rule: after _dispose, the object should be as well defined
as it was after _init.  I.e., anything you free you set to NULL
and you don't free anything that was allocated in _init[*].

M.


[*] Unless you allocate a new dummy object to put in its place.
That wouldn't make much sense unless you have big trouble
with circular references.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObjectClass.dispose and bringing objects back to life

[Morten Welinder]

Benjamin Otte o...@gnome.org wrote:

 But then I looked at [gnumeric] and I realized
 it doesn't do anything of that. So I'm inclined to think that what
 you're talking about is more about an ideal world that you wish we all
 aspired to, but is not in any way related to how people write code in
 the real world.

We take bug reports.  We even fix bugs.

I cannot really use pointing 400k lines of code for anything, so
throw me a bone -- a class name, for example -- and I can actually
do something.

(And if you just meant to throw a few insults my way, well I
hope you feel better.)

M.
(not quite an angel himself)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Morten Welinder]

  if (1)
    {
      glocal_object GFile *file =  g_file_new_for_path (/tmp);
      glocal_string gchar *basename = g_file_get_basename (file);
      g_debug (Basename is '%s', basename);
      // look ma' no leaks!
    }

This is, of course, cute but I don't think this would actually catch many of the
non-trivial leaks that make it into the code base today.  Those are typically
not scope based -- possibly because the attention span of the average
programmer is long enough to cover the writing of a whole function, ;-)

The current serious leak cases I see are:

* The dispose or finalize method of an object type fails to free some
stuff.  This is
  quite common.
* Cyclical links.  The resulting leaks are typically quite big.

A case scope-based destructors would handle is this:

* Multiple return statements, typically for error handling, where one or more
  branches forget to free stuff.  Cursory valgrinding doesn't catch this because
  the code doesn't get exercised.

The case isn't uncommon, per se, but programs don't hit the cases often.

M.


PS: The situation where scope-based destruction is important is for languages
such as C++ with exceptions in use.  C with  GObject is not such a language.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: experimental gtk+ 3.3.2 win32 build

[Morten Welinder]

 In general, we are interested in improving the situation with respect to
 Windows builds.

Perhaps then you could take care of bug 614920 (gtk redefines
a system structure type).  Obvious patch in comment 4.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib Atomic Operations

[Morten Welinder]

 what is the purpose of  '(void) (0 ? *(atomic) ^ *(atomic) : 0)'?

Poor man's type check.  That expression isn't valid for every
possible atomic.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib next cycle update

[Morten Welinder]

 Unfortunately this is a pragma

Will C99's _Pragma help?  That can be put in a macro.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Leakage of Toolbar-Related Menu Items

[Morten Welinder]

Currently Gtk applications leak quite a lot when menu items are created
for GtkToolItems.  This is because circular links prevent the tear-down:

+---+ (menu_item)+---+ (child)+-+
|GtkToolItem|---|GtkMenuItem|---|GtkAccelLabel|
+---++---++-+
   ^ |
   |  (accel_widget) |
   +-+

(That is going to look weird unless you use a fixed-width font.)

GtkToolItem is not a GtkWidget, so it doesn't receive the destroy
signal that normally helps tear down circular links.

This is bug 645483 with no responses.  I have contacted the author
who introduced the circularity,  jpeter...@openismus.com, but I
have received no response.

The question is what should be done about this.

1. Make the accel_widget link a weak ref.
2. Declare a destroy signal on GtkToolItem and make sure it gets
   sent by containers of such items, i.e., something parallel to
   GtkWidget's destroy.
3. Destroy the menuitem in GtkToolItem's dispose handler.  (And
   in one other place where we disown the current menu item.)

I don't really like version 1 because there are simply too many reasons
why the menu item would have extra refs.  That is, it would not work in
general.

Other options?

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: About gsettings aborting on unkown schemas

[Morten Welinder]

 The core principle that allows most functions to always succeed is
 that programming bugs are not thrown, they just terminate the
 program.

Havoc, the data doesn't agree with that assertion.
Let's look at numbers:

glib, number of not-crashing on programmer errors:
# find glib -type f -name '*.c' -print | xargs -n100 grep -E
'g_return_(val_)?if_fail' | wc -l
1509

glib, number of crashing on programmer errors:
# find glib '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
213

gtk+, number of not-crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_return_(val_)?if_fail' |
wc -l
5637

gtk+, number of crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
693

So the overwhelming conclusion is that glib and gtk+ handle programmer
errors by issuing a critical and returning. Not by crashing.

It tips even more in that direction when you realize that a good
fraction of the crashing calls do not actually catch (library user)
programmer errors, but problems more in the memory-corruption
department.

We know that not having the schema around is not good.  Going postal
and killing the program is not the solution.

Doing a g_return_val_if_fail is fine here.  That will give the user a
chance of saving his work.  This is in contrast to g_error which is a
sure way of eating data.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: About gsettings aborting on unkown schemas

[Morten Welinder]

 you can say that all you want, but it's absolutely *not* a bug.

Of course it is.  With this bug, programs crash where they other-
wise could limp on.  It's like changing all g_return_if_fail calls
into asserts -- after all, any time one of those hits it represents
a bug somewhere.  My log files suggest that all the time is
a good approximation of how often that happens.

It is absolutely not like missing your main ui file.  You can't limp
on from that in a meaningful way.

And note, that in the gconf age handling this was not a problem
at all.

This bug makes it hard to keep multiple versions of a program
installed without making settings per-version which has its own
problems.  If a setting is ever removed, the old version won't
run.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Crashes with long words in strings passed to gtk_widget_set_tooltip_text()

[Morten Welinder]

 If you really want to safely pass a very long text,
 you will have to know the font (family and size) then check with stuff
 like pango_layout_set_text() and pango_layout_get_pixel_size().

This happened in Gnumeric at some point too.  Basically, every time user
supplied string make it into tooltips, this will happen.  So it's
probably better
to fix this in gtk+.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

clipboard_get_timestamp

[Morten Welinder]

Once code starts looking like an #ifdef soup it might be time to introduce
a method on, say, the window object.

IMHO, of course.

Morten



#ifdef GDK_WINDOWING_X11
  if (GDK_IS_X11_WINDOW (window))
{
  timestamp = gdk_x11_get_server_time (gtk_widget_get_window
(clipboard_widget));
}
  else
#endif
#if defined GDK_WINDOWING_WIN32
  if (GDK_IS_WIN32_WINDOW (window))
{
  timestamp = GetMessageTime ();
}
  else
#endif
#if defined GDK_WINDOWING_BROADWAY
  if (GDK_IS_BROADWAY_WINDOW (window))
{
  timestamp = gdk_broadway_get_last_seen_time (window);
}
  else
#endif
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Reviewing Win32 Patches

[Morten Welinder]

Any chance of getting reviews of patches for Win32 bugs?

https://bugzilla.gnome.org/show_bug.cgi?id=614920
https://bugzilla.gnome.org/show_bug.cgi?id=619564
https://bugzilla.gnome.org/show_bug.cgi?id=617874

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Morten Welinder]

 What global state, for instance?

locale?

As a reminder, setlocale is not thread-safe.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Morten Welinder]

 Sorry, I don't understand. Could you explain in more detail?

If you need to run two different windows in two different locales, then
single-instance is not possible.  For Gnumeric this happens regularly
due to the world's decimal separator mess.

The reason you cannot do this in a single instance is that (a) setlocale
is not thread safe, and (b) libraries like gtk+ like to start their own
threads out of your control.

 Why would
 two separate instances (separate processes) of the same app care if
 setlocale is not thread safe?

They wouldn't.  I didn't mean to imply that.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Morten Welinder]

On Thu, Feb 24, 2011 at 5:55 PM, Colin Walters walt...@verbum.org wrote:
 On Thu, Feb 24, 2011 at 5:15 PM, Morten Welinder mort...@gnome.org wrote:

 What actual problem was solved by all this infrastructure to keep just
 one instance?

 Basically for any application which manipulates private files in any
 form (in Firefox' case, this is the history database), it avoids data
 corruption with uncontrolled access by multiple processes.

That's an excellent reason for making single-process available, but not
an argument (either way) for making it the default.  It certainly doesn't
sound like a problem experienced by, say, evince.

What is the GtkApplication solution to dealing with different environment
variables, including DISPLAY and LANG?

I believe the single/multiple instances is a decision for the developer and
not one Gnome or Gtk should have an opinion on.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Morten Welinder]

 There are many other reasons to not use single instance.

I agree.

d. Running on a different $DISPLAY.  Look and you'll find no end of
complaints over firefox' inability to do this sanely.

e. Running with different locale settings.  This happens for Gnumeric
when people want different decimal separator for different files.

f. Limiting what documents script see.

 If GtkApplication can not turn off single instance,
 I will not use it when I do not need single instance.

Ditto.  Or I'll create an id like gnumeric-$PID

What actual problem was solved by all this infrastructure to keep just
one instance?

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkBin as a publicly derivable abstract class please.

[Morten Welinder]

 Today I found '_gtk_bin_set_child()'

 what's wrong with gtk_container_add()?

If _gtk_bin_set_child was needed to subclass GtkBin inside
gtk+ then it is just as needed outside.  So your question should
really be answered with the counter question of why is gtk+
not using gtk_container_add?

Out-of-tree widgets should not be second-class citizens.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: freezing for GLib 2.26

[Morten Welinder]

 I plan on branching glib-2-26 early next week and removing GApplication
 (and related classes) from the branch.

GDateTime still has API issues.  g_date_time_new_full does not
have enough arguments to uniquely identify a time.  For example,
one of these is going to be mistaken for the other:

# TZ=US/Eastern perl -e 'print scalar localtime 1289109599, \n;'
Sun Nov  7 01:59:59 2010
# TZ=US/Eastern perl -e 'print scalar localtime 1289113199, \n;'
Sun Nov  7 01:59:59 2010

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH] gdk/gdkpixmap.[ch]: state constness of `data` in create pixmap routines

[Morten Welinder]

 The public interface for the following routines are affected by the
 patch, however this should not affect any software calling into the GDK
 library.

What do you build that assertion on?

Have a look at the program below.  With const, the
second foo call causes gcc to complain over types.

Also, code assigning the address of any of the affected
functions to variables will become invalid.

Morten



static void
foo (const char **x, int n)
{
  const char *y = x[0];
  (void)y;
}



int
main (int argc, char **argv)
{
  const char *x1;
  foo (x1, 1);

  char *x2;
  foo (x2, 1);

  return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Faster UTF-8 decoding in GLib

[Morten Welinder]

 That's one of the worst ideas as far as software goes.  If an operation takes
 1% of your application time and you make it 1000 times faster, you know how
 much total faster your application would run? 1.01x faster...

Behdad, that line of argument is only valid for code that is used
by one application only -- in the same way saving $1000 in a $1M
project is pointless, but saving $1000 is a thousand projects years
after year does make sense.

This kind of proposal should be debated on the merits.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: When deprecating, always say what the replacement is.

[Morten Welinder]

 As a matter of fact, it is. There is not supposed to be any
 replacement for the stuff that says Do not use it. Everything
 that has a replacement is however documented.

 So please, a little research before bashing perfectly good commits.

How about a research before bashing perfectly good bashing?
(And look for Do not used it. before calling it a perfectly good
commit.)

But seriously, Do not use it is unhelpful.  Things no longer
compile for someone and all you have to offer is you shouldn't
have been doing that?  We can do better than that!

For GTK_WIDGET_FLAGS, for example, one could point to
a list of the accessors for the individual flags.  That is, as I
understand it, what one is supposed to use instead, even if
it is clearly not a 1-for-1 replacement.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Testing for memory leaks in GTK

[Morten Welinder]

You probably need to end with something like this
(from Gnumeric):

{
GSList *displays;

gdk_flush();
while (g_main_context_iteration (NULL, FALSE))
;/* nothing */

displays = gdk_display_manager_list_displays
(gdk_display_manager_get ());
g_slist_foreach (displays, (GFunc)gdk_display_close, NULL);
g_slist_free (displays);
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Valgrind and GTK

[Morten Welinder]

There has definitely been a degradation in the ability
of valgrind to find memory leaks in gtk+ applications
over the past, say, 5 years.

I think the basic problem is that there are more singletons
and that gtk+ object hold more pointers to other objects
than they used to.

IMHO, the situation could be greatly improved if there was
a gtk+ function, say gtk_cleanup, that

* Eliminated singletons
* Cleared caches
* Called similar cleanup functions for libraries used by gtk+

subject to the constraint that gtk_cleanup should leave the
library in a usable state (and hence that you can call it as
often as you want -- that's important for a library).

Both fontconfig and cairo got this last point wrong.  Their
cleanup functions are basically only good for asserting
that there were no leaks which is not helpful in the gtk+
case.  As a consequence, pango is unable to clean up
its object allocations.  And I can't even blame Behdad.

Maybe there should also be a function to handle all pending
events at exit so the display related structures are not leaked.

Note: the above proposal does nothing to address the type
system related leaks, but they are the ones best suited for
suppressions anyway.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Are Out-of-Tree Widgets Second-Class Citizens?

[Morten Welinder]

A long time ago GTK+ was a collection of widgets.  If you did not like
what you had,
you could grab the source of one of the widgets and change it to do whatever you
needed it to do.

This is increasing no longer the case -- in-tree Gtk+ are now special
and programmed
using a different API than out-of-tree widgets.  This is wrong!

Consider GtkLabel as exhibit 1.  This is the vanilla flavour of
widgets.  I should be
able to copy gtklabel.[ch] into my tree, rename all identifiers and
end up with a
new widget functionally identical to GtkLabel.  It does not work because it will
not compile.  GtkLabel is using, for example, things like widget-window and
widget-allocation.

This is a consequence of the halfway G_SEALing that was done.  Insofar G_SEAL
is a good idea, it should apply to GTK+ itself, i.e., GtkLabel has no business
messing with the internals of GtkWidget, although obviously it should
have access
to its own internals.  (Doing so would also send some of the conversion pain
back to people who inflict it on others.  That might discourage the habit of
breaking APIs and ABIs without good reason.)

Consider now GtkRadioButton as exhibit 2.  This would probably be the chocolate
flavour.   Note, that GtkRadioButton is derived from GtkToggleButton.
You cannot
make a copy of GtkRadioButton for several reasons:  First, G_SEAL makes it
impossible to set GtkToggleButton::active which is something that
gtk_radio_button_clicked has a reasonable interest in doing.  There in a
setter function, gtk_toggle_button_set_active, which does the same as setting
the property, but it just calls the clicked method -- instant infinite
recursion.
Secondly, the code uses various _gtk_* methods that were, evidently, useful
enough to implement a small handful of widgets but not useful enough to make
public.  I am not sure how you would work around the lack of
_gtk_button_set_depressed, for example.

So there you have it:

1. Please make G_SEAL apply also within GKT+.
2. Please stop using _gtk_* functions to be extra friendly to in-tree widgets.

(There are likely a few places where _gtk_* functions make good sense: the
interaction between widgets and size-groups comes to mind.)

Morten Welinder



PS: I did find a way to set GtkToggleButton::active for Gnumeric.  Let us just
describe it as not pretty.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [patch] constify g_simple_async_result_set_from_error

[Morten Welinder]

 With this change, it won't break (or add warnings) to any program. It
 just removes a warning for programs that do not do the explicit cast,
 and get given a const GError.

Really?

Take the program below and notice that the constified prototype
introduces a warning.  If used from C++, that would be an error.

So this change is an API break.  That is not to say that it might
not be justified, but let's call it what it is.

Morten




static void foo (const char *s) { (void)s; }
static void bar (  char *s) { (void)s; }

int
main (int argc, char **argv)
{
  void (*f1) (char *) = foo;
  void (*f2) (char *) = bar;

  f1 ();
  f2 ();

  return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GZip{In,Out}putStream in GIO?

[Morten Welinder]

 Does libgsf use the GIO APIs?

It can take a GFile* and treat that as a zipfile.  The way you
would read from the zipfile member files would not be GFile*
based.  For the output side, turn all that around.

Does that answer your question?

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GZip{In,Out}putStream in GIO?

[Morten Welinder]

 FWIW, Sugar uses zip quite extensively to bundle content and software
 and we would love to move from using python's zipfile to something
 glib-based.

Why all this reinvent-the-wheel effort?  libgsf gives you access
to zipfiles and is glib based right now.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: The GTK+ file chooser

[Morten Welinder]

 What you are showing there are applications using the file-chooser
 incorrectly. In particular they don't set the window size large enough
 (or they forget to remember the user-chosen size).

Add a preview: no space left for files.
Add a filter: no space left for files.
Add file format selector: no space left for files.

Solution?  Blame the applications.

Fixing the size-request method is only the beginning.  Right
now anything you add canibalizes internal space instead of
requesting more.  Fixing that is a start, but then you would
quickly end up with a dialog bigger than the screen.

Places is wasting acres of real estate right now and it cannot
even be squeezed: side divider can extend it, but not shrink it.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Native file chooser dialog on Windows

[Morten Welinder]

 and confusing
 gradual display of network locations (the first time I tried opening
 something from my fileserver I thought some of my directories went missing

I think this could actually be improved fairly easily for
all platforms if something (the chooser or backend,
not sure) was more careful of the order it stats stuff.

From the name of entries, it should be possible to come
up with a fairly good guess of what to stat first.  We want
directories before files and things alphabetically within
those groups, except that dot files should be last if they're
not going to be displayed.  That makes it a problem of
guessing what is likely to be a directory.  I'd try looking
for an extension which would typically indicate something
that isn't a directory.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: The GTK+ file chooser

[Morten Welinder]

 IMO this is now pretty much of a non-issue, since the current GTK
 file selection dialog is sufficiently like Windows (but nicer!).

I'm not sure what planet you're living on.  The current gtk+
file chooser absolutely stinks!  It fails miserably in its
primary task: showing the user what files are there in
order to let the user pick one.

In particular is it very, very bad at managing its screen real
estate.  See

http://blogs.gnome.org/mortenw/2009/01/21/the-gtk-file-chooser-dialog/
http://blogs.gnome.org/mortenw/2009/02/23/the-gtk-file-chooser-dialog-take-ii/

(The first is mostly for context.  SuSE shipped with a bad bug.)

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: fsync in glib/gio

[Morten Welinder]

This is crazy.

People are actually advocating that thousands upon thousands of applications
need to be changed.

Yes, POSIX allows this particular idiotic behaviour.  So what?  It probably also
allows free() to do nothing, yet no-one in their right mind would want that.  Or
maybe you would be upset if the code fragment

const char *s = x;
int i = (s+1)-s;

formatted your hard drive.  Yes, the C standard really does allow that
to happen.
(C99 section 6.5.6 #9, if you really want  the details.)I don't
know about you,
but I would return the compiler with a big Broken! label if that happened.

The mere fact that a standard allows an idiotic implementation doesn't mean
we should play ball with it.  The same standard also allows sane
implementations.

We could litter fsync() calls all over, but...

1. It describes a semantic that isn't really what we want.  In fact,
there is no way
to get exactly the semantics we want with POSIX.   We have to ask for the
please-wait-for-the-disk semantics we don't want.  That's a sure
way of getting
sluggish programs.

2. Shell scripts, Makefiles, and other languages without explicit
fsync control will
kill really you.  Instead of...

foo file file.new
mv file.new file

...you get to write...

foo file file.new
sync
mv file.new file

Performance might be affected.

3. Auditing and changing thousands of programs?  Expect bugs.

We already break the strict letter of POSIX and the C standard in
fifty different ways.
If someone shows up with an environment that doesn't behave as we want, we
say sorry, no ball.  Just add stupid file systems to the list.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: fsync in glib/gio

[Morten Welinder]

I think I am in line with what Michael is saying here: there is a
non-trivial risk that littering fsync all over the place will badly
affect existing systems.

The ext4 attitude is interesting, btw.  They are saying that
POSIX allows this behaviour so it's your problem.  But when
the gcc people say The C standard allows this or that, then
the kernel people question the sanity of gcc developers several
generations back.

F*** POSIX allows this!  A program that does open-write-close-
rename should not be left with an empty file in case something
goes wrong.  The old file, or the new file.  Anything else is insane
and by extension the kernel developers and their ancestors.

The world is full of crappy hardware, drivers, electricity suppliers,
cable-pulling clumsy people, etc.  They are all out to get you,
so there is no reason why the kernel should hand them your
data too.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ 3.0 Theming API Hackfest Minutes

[Morten Welinder]

Were there any discussions on fault separation between the
application and the theme engine?

The current state of affairs is that theme engines have a long
record of crashing applications or even changing their functionality.
When that happens, the user blames the application and, sometimes,
files bugs against it.  Application developers are left with bugs that
cannot be reproduced.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: client-side-windows vs metacity

[Morten Welinder]

What about other window managers?  It would be sad to see gtk+
tied directly to a given window manager.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Top-level include files

[Morten Welinder]

 Its supposed to be documented in the api docs, at the top of the
 synopsis for each section. Of course, the documentation may be
 outdated.

This is a farce.  Why try to enforce something that does not seem to
have ever been documented?  At least not correctly.

On http://library.gnome.org/devel/glib/stable/glib-compiling.html we have:

The recommended way of using GLib has always been to only include the
toplevel headers glib.h, glib-object.h, gio.h. Starting with 2.17,
GLib enforces this by generating an error when individual headers are
directly included.

That's wrong.

http://library.gnome.org/devel/gdk/stable/ has nothing similar that I
can find.  The synopsis for Key Values lists only gdk/gdk.h.  In the
body there is a note about gdk/gdkkeysyms.h

Humble suggestion:

1. Correctly document which header files can be included by
applications.  Then worry about enforcement.

2. Make sure tests and demos subdirectories follow the policy.

3. Then worry about enforcement.

In that order.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Top-level include files

[Morten Welinder]

Someone is pushing changes to the way Gnome modules include header files,
see http://live.gnome.org/GnomeGoals/CleanupGTKIncludes

 GTK+ is moving toward a model where it is only allowed to include the 
 'toplevel'
 headers. Only glib.h, gdk/gdk.h, gdk-pixbuf/gdk-pixbuf.h and gtk/gtk.h
 can be directly included.

This would be nice advice were it not for the fact that it is wrong
and it is being
spread far and wide.  One exception is gdk/gdkkeysyms.h and it is not alone.

So: what header files are meant to be included by applications?  Where is this
information documented?

I have been trying to get this information via bugzilla, wiki, irc and
not the mailing
list.  The best answer, so far, is see if it compiles which is a
sad, sad statement
about the API.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ Team Meeting - 2008-09-23

[Morten Welinder]

 I disagree. If we keep gtk_hbox_new() and gtk_vbox_new() around,
 we can't change the packing defaults, which is a *huge* benefit
 of introducing a new class with new API (GtkBox was abstract before,
 so now allowing to instantiate it is in fact a new widget, and
 that has to be reflected in *new* API to be able to change its
 behavior).

A *huge* benefit?  Would you care to elaborate, concretely, what the
*huge* benefit of overriding defaults could be?
How does it compare to the cumulative *enormous* pain distributed
over all application developers?

We are discussing changing a very fundamental widget class here.  I
don't care too much what you do with GtkHScale -- just keep
gtk_hscale_new around as a convenience function.  (I call it that so
you don't get the idea that it should be deprecated.)
But GtkHBox?  Do you really want to send another giant Fuck You! to
anyone who has working Gtk+ code?

 Also, can we simply change the return value of functions?
 (returning a GtkBox where we used to return GtkVBox and GtkHBox).

gtk_hbox_new returns a GtkWidget*.  As long as GTK_HBOX and
GTK_IS_HBOX exist and do the right thing, breakage should be minimal.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ Team Meeting - 2008-09-23

[Morten Welinder]

 I think the general problem is that if you have a box type that can
 change orientation on the fly, what type is it? A HBox or a Vbox?

I cannot actually imagine why I would want such a box, but if you
wanted to you could do

#define GTK_IS_HBOX(w) (GTK_IS_BOX(w)  gtk_box_is_horizonal((GtkBox*)(w)))

Sure, the widget could change orientation later, but existing code
does not do that.

Would someone please elaborate on these *huge* benefits this is
supposed to bring?

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ Team Meeting - 2008-09-23

[Morten Welinder]

If all you really want is to change the defaults for box packing, then
why isn't that all you are proposing?  It would be a simple 1-line
patch to gtk_box_pack_start_defaults, if I understand things right.

Some thing will break if you do that, but nowhere near as many things
as with changing the default plus getting rid of hbox/vbox. I suspect
it would not be that many things, because most things currently use
the unaffected box packing methods.  This would be an API break --
semantics changed -- but I don't think the impact would be all that
big.  Glade files, for example, seem to have explicit shrink/expand
data.

If all the benefits is in changing the defaults, there is positively
no reason to run around and deprecate hbox and vbox.  If that part has
a secret benefit (*huge* or otherwise) then weigh that against the
pain for application developers.

In other words: you seem to be proposing two separate things here,
only one of them has any stated benefit -- you say *huge*, I say
save-the-occasional extra line.  The other part no-one is even trying
to defend and it is clearly going to be painful for application
developers, especially for anyone targeting 2.x and 3.x at the same
time.  Drop that part asap.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ Team Meeting - 2008-09-23

[Morten Welinder]

 I don't think the minutes reflect what was said in the meeting here.
 My understanding was hat the H/V subclasses get deprecated as soon
 as the code to enable flipping in their parent classes is in SVN.

If, say, gtk_hbox_new was to get deprecated and disappear in 3.x then
it would be near-impossible to write a program to compile against both
2.x and 3.x

Do we really, really need to impose that pain on developers?
Or am I misunderstanding what is being proposed?

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ Team Meeting - 2008-09-23

[Morten Welinder]

 How is this different from any other deprecated function that got
 replaced by another one and will disappear in 3.0?

1. The number of uses of hbox and vbox is *huge*.  Working around it
with an #ifdef or two is not going to work well.  We're easily talking
hundreds of instances here for a single application.

2. For most other deprecations, there is a 2.x version against which
you can write code that ought to work also in 3.x.  It is not clear
that there will be for this case, let alone a generally deployed
version of 2.x

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ Team Meeting - 2008-09-23

[Morten Welinder]

 * Deprecate the H/V split and add orientation instead
 + mitch has a patch deprecating all the H/V classes
 + adds a constructor for base classes
 + defaults can be fixed
 + subclassing is easier
 + change orientation at runtime
 + massive deprecation at branch for 2.90
 + everyone agrees
 ACTION: mitch files bugs with the various patches


This late-cycle deprecation will make it hard to write code that is
kosher in both the old and the new world.  That is really a bad idea,
even compared to the regular deprecation pain.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

[Morten Welinder]

2008/8/25 Mathias Hasselmann [EMAIL PROTECTED]:
 Hi,

 The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES
 and GTK_STOCK_NO encourages creation of horrible user interfaces.

What a terrible idea!

First, GTK_RESPONSE_YES and GTK_RESPONSE_NO do not imply
much about user interfaces, good or bad.  They are response codes,
nothing else, and can be paired with any GTK_STOCK_* in full
observance of the HIG.

Second, for GTK_STOCK_YES and GTK_STOCK_NO, do you really
want to break a pile of GTK applications just because they run afoul
of a related project's (i.e., Gnome's) guide lines?  Note: guide lines
are not strict rules.

(For the record, I seem to have lots of _RESPONSE_  lying around,
but no _STOCK_ ones.  Unless they are somehow hidden in glade
files.)

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: About GTK+ 3.0 and deprecated things

[Morten Welinder]

 Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile...
 (e.g., I remember doing that for gftp, not a trivial app.)

That sounds like a serious case of selective memory.  Or maybe gftp
has the ui from hello, world.

Here's a partial list of suffering that we went through.  Let's see...

* All widgets has to be reworked and audited.  There was new reference
  handling and double destroy calls added to the trouble.

* All glade files needed to be redone, or at the very least subjected to
  heavy post-translation surgery with Emacs and Perl.

* All code needed to be audited for UTF-8.

* All font handling had to be reworked.  Drawing changed too.

* Whenever something crashed, leaked, or otherwise simply did not work,
  we had to audit not only our own code, but glib, pango, and gtk+ too.
  There were piles and piles of bugs in the new code.

* We had to struggle with sluggishness of the resulting gtk2 application.

The above is just what I can remember off the bat and is *before*
changing to use the new widgets of gtk2, some of which were only
partial replacements of what they deprecated: the tree view, for
example, was touted as right for all kinds of tables, but it has
become clear that it cannot handle large ones.

Gnumeric has about 34k lines dedicated to dialogs, not including code
that implements the actions of those dialogs.  Add to that 20k lines of
widgets and another 20k lines of further gui code.  That excludes code
for graphs.  You just do not audit that in a weekend or two.

You want us to go through some variant of that every 3-4 years?  That's
insane!

What, exactly, is it that is hard about maintaining 2.x that will not be
hard for 3.x?  I have seen nothing but unsubstantiated assertions
about this.  What I have observed is that sub-systems like GtkPrint
get dumped in and abandoned right away.  With bayesian mind
that tells me that the maintenance situation will not be better for 3.x

What really bothers me is that people go out of their way to break working
code.  Looking at svn logs tells me that the effort of keeping the old widgets
and methods around is minimal.  It's not just the old gtkclist -- the recently
deprecated gtktooltips shows the same thing.  The second unsubstantiated
assertion is that the deprecated widgets cause a lot of maintenance work
beyond the self-inflicted pain of deprecation.  The data does not support
that assertion.

I would like to see all this gtk3 talk pushed 3-4 years out into the future.
There are lots of things that need to be fixed and introducing new,
buggy code elsewhere is not going to fix it.  If that means the world
will have to wait for animated, semi-transparent widgets, then that
would be fine.  No real work will get done of behalf of those features
anyway.

Morten Welinder

PS: For whatever it's worth, GnuCash also took years to go gtk2.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Justifying the GTK+ 3.0 ABI break

[Morten Welinder]

 Or maintaining a bunch of deprecated API?

I looked at the log for gtkclist.c and the majority of the changes over the
past five years are a direct consequence of the api having been declared
deprecated.  Specifically there is a lot of defining and undefining of
GDK_DISABLE_DEPRECATED going back and forth there.  Even so,
not much is going on.

So the maintenance burden, to the extent there is one, is _caused_ by
deprecation.  And that's even within gtk+.

Pretty ironic, isn't it?

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Justifying the GTK+ 3.0 ABI break

[Morten Welinder]

 So the maintenance burden, to the extent there is one, is _caused_ by
 deprecation.

 This is ridiculous

Nobody is laughing and you are not reading what I wrote carefully
enough.  It really is the elaborate deprecation (as opposed to simply
dropping in a comment and not maintaining the code any more) that
is causing the burden.  That's what the log say -- assuming gtkclist
is representative -- which I would guess it is.

In other words: keep the interfaces around instead of causing grief
for applications on a weekly basis.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GHashTable and const

[Morten Welinder]

 Because const in C is crippled, unlike in C++ where its actually useful.


 Soory, but you aren't right:

Yes, he is, but you did not understand him.  He was making a language
comment, not an implementation comment.

const in C does not propagate as usefully as you would like.  Therefore,
the following sniplet is not violating C rules:

struct Foo { int *x; };
int foo (const struct Foo *p) { *(p-x) = 1; }

While I cannot change p-x, I can change what
That said, it still wouldn't hurt to add const for cases like g_hash_table_size.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gio build failure on Irix

[Morten Welinder]

That looks like a job for configure.  In fact, had it been there, no extra
patch for irix would have been necessary.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: proposal: substantial change to keyboard-driven action handling

[Morten Welinder]

  There needs to be a 1:1, configurable mapping between any tuple of
  these 3 properties and some action within a GTK application.

Why on Earth would you require that mapping be 1:1:?  What you need
is that action is a [mathematical] function of the 3-tuple.  There is nothing
wrong with invoking the same action for two different keys.

I wonder how this can be done while maintaining some measure of ABI
stability.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_strsplit variant which filters empty strings from the result

[Morten Welinder]

Do you have a case where it would actually make sense to use such
as function?  The file name case is an awful one:

1. It's unix-specific.  On win32 you can see /foo/bar\baz\bof

2. It fails to distinguish //foo and /foo which, even on unix, are two
different file names.

It seems to me that such a function is a tad special for a general library
like glib.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Using more verbose ChangeLog format for GLib and GTK+

[Morten Welinder]

This seems to be a solution looking for a problem.  I don't think we
need another barrier to participation in gtk+ maintenance.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [TreeView] Performance of TreeView with huge lists

[Morten Welinder]

This comes up regularly for various large values of N.

 Just as random thoughts, is there any way that giving a user a list of
 100 million items is going to be useful?  If you already know that the
 user will never see all of the list, why try to display it?

You do not want to do that is not particular useful advice when, in
fact, he does want to do that.  One would want to do this when one
cannot tell in advance what smallish part of the large view that the
user wants to see.  A database viewer, for example.

 And searching through this list for a specific item using the
 scrollbar is going to be very tedious, if not impossible, for the user.

Impossible -- one pixel could be a million records, which only tells us
that the table needs to be navigated some other way.

Thorsten, try looking into ETable as used by Evolution (though not
necessarily recent versions - I last looks 5 years ago).  It is not a
beauty, but it might fit your needs,

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_build_filename and members

[Morten Welinder]

On Jan 6, 2008 3:43 PM, Mikael Hermansson [EMAIL PROTECTED] wrote:
 Hmm just saw that g_build_filename does not work for GIO Uris

 its simply strips away separator for example:

 g_build_filename(file:///, g_get_home_dir(), foobar.txt, NULL)

 will be:

 file:/home/user/foobar.txt

It's hard to see how any other result could be right.  You are, after all,
telling it that you have a directory called file:.

As an aside, the a simple concat of the above would yield something
like file:home/user/foobar.txt with four slashes in a row.  That would
correspond to the file //home/user/foobar.txt which is [well, can be]
different from /home/user/foobar.txt, but glib/gtk+ gets that difference
wrong.

Does gio properly handle the difference between file://, file:///,
and file:?  (Relative filename, absolute filename, and absolute
filename in alternate space respectively.)

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_format_file_size_for_display()

[Morten Welinder]

The practical use of such a function is to give the user a general idea of
the size.  Hence a 2.4% (k), 4.9% (m), or 7.4% (g) difference will
not change the picture.

However, something people need the full story.  Therefore, the friendly
application using such a function should probably consider having a
tooltip telling the full story.  That would be a good time to show
things like read-only too.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: SoupInputStream / trying out gio

[Morten Welinder]

 Specially as you can use #undef in your C code, when stuck with a
 platform doing such stupidities...

Aha, a member of the standards-don't-apply-to-me school, :-)

Yes, you might #undef, but then you would not be able to use the
corresponding library function anymore.  For example, if a platform
does

#define stat stat64

then you are going to have problems with anything that wanted to call
stat and anything that uses struct stat -- in the latter case, the structure
likely changed size which isn't healthy.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: SoupInputStream / trying out gio

[Morten Welinder]

 I added an extra check for -write != NULL in the splice case (because
 write() already did that) and commited.

I would be to avoid having struct members called write.  That is a reserved
symbol and if the C library decides to use a macro you will have some very
interesting effects.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GInterfaces and API Stability

[Morten Welinder]

I notice that there are no padding members in, for example,
GtkCellLayoutIface.  Adding members therefore will change the
struct size which sounds like a clear ABI change to me.

Anyone who did

typedef struct {
GtkCellLayoutIface clif;
Bar baz;
} Foo;

is going to see random crashes when dynamically linked with a newer
gtk+.  Not good.  So even the C ABI was broken with

http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkcelllayout.h?r1=12573r2=16976

GtkWidgetClass, on the other hand, has extension member to be used
for new signals.  That does not suffer from the above.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GInterfaces and API Stability

[Morten Welinder]

 Whyever would you do that? Such a struct would never be useful.

It is a simple use of an existing type in the API.  I can create my own
instances of such a type, even if I cannot hand them off to anything
GObject related.  I could store signal handlers there, for example.

Bottom line: a published type changed size.  ABI break.

I don't know if any applications out there do this and you probably
don't either.  But it is a valid thing to do.

Maybe there should be an API/ABI stability documented that spells
out the rules.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: GLib testing framework

[Morten Welinder]

 nobody has to use this syntax. you can stick to the ever simple:
g_assert (foo  bar);

 however if you want the value of 'foo' and 'bar' be printed out, instead
 of just the value of (foo  bar) which would be 0 or 1, then there are
 no other means than using something simialr to:
g_assert_cmpfloat (foo, , bar);

No other way?  You just need to think outside the box^w^wcpp.  How
about a pre-cpp filter that looks at the source code, finds the g_assert,
and does a little creative rewriting?

That would be a ten-line perl script.  Plus some Makefile magic to hook
it up.  There would be no extra run-time penalty and the compile-time
penalty would be near-zero.

Note, that the filter should preserve line numbers, i.e., never remove and
never insert newlines.  Otherwise error messages with line numbers would
drive you crazy.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: turning g_assert* into warnings

[Morten Welinder]

That's pretty much a no-go.

g_assert_warning is marked G_GNUC_NORETURN.

If you return from such a function, there is no telling what incorrect
assumption the
following code was compiled with, i.e., things that the compiler thought were in
registers all of a sudden are not.  Crash.  Burn.  Toast.

If you remove G_GNUC_NORETURN, you are going to get an unpleasant number
of might/is used uninitialized warnings.  And if you do return, you
get the same
problems with bad assumptions as above, only this time in the client program.

All of this leads to the conclusion that g_asserts should be used
sparingly, i.e.,
for things where the program is in a really bad shape and has no idea about
how to limp on.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Undo framework

[Morten Welinder]

I would find it useful if such an undo system would do away with the stack
view of things and use the back-in-time view that Emacs uses.

For example, if we have

  Do A, Do B, Do C, Undo C, Do D

then it should be possible to rewind history to the point where C was done.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ Theming improvements

[Morten Welinder]

The thing I miss from your list is how to make sure themes' code does not
crash the innocent application into which they get loaded.

There have been several rounds of obscure bug reports for Gnumeric that
basically came down to theme code bugs.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Multiple GdkScreens?

[Morten Welinder]

 Are there other platforms on which Gdk may have more than one screen?
 Or if multiple X servers are running, with multiple copies of Gnome,
 do they still share the same gdk?

Gnumeric under X can use multiple screens (or displays for that matter).

It's quite useful to have multiple screens if xinerama doesn't fit your needs.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Blacklisting themes?

[Morten Welinder]

I was thinking more of gtk+ blacklisting the theme, but nevermind that.

 4. User updates gnumeric, and can't run it anymore because it barfs on
 that engine.  He still risks crashes in other apps.

Not quite.  Gnumeric starts with default theme, looks strange, but works.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Blacklisting themes?

[Morten Welinder]

In light of bug 438456, is there (or should there be) a way to
blacklist a certain
theme engine for a certain version range?

Bug 438456 causes memory corruption in any gtk+ application it is applied to.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Blacklisting themes?

[Morten Welinder]

 I don't see how this is different from any other memory corrupting bug
 in, say, a library.

From a technical standpoint it is not.

However, a theme is a library that is loaded into your application by
the end-user.
Even if he is not particularly aware of doing so.

The application programmer has no choice in the matter and cannot
really test with
all kinds of themes and all kinds of versions of them.  But the
resulting crashes are
still going to be blamed on the application and poor me.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkBuilder Public API - Last call

[Morten Welinder]

 user_type and user_data which I proposed doesn't make too much sense, it's
 also difficult to support since you can't (AFAICT) use a GValue as user data.

It would be marginally useful for providing constant user data like...

* Strings: oink
* Translated strings: _(Moo!)
* Integers: GINT_TO_POINTER(12)

Having integer arguments saves you a function if you have, for example, Up
and Down buttons that are handled almost identically.

M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkBuilder Public API - Last call

[Morten Welinder]

 Since it accepts a nick, name or number, it's using
 g_enum_get_value_by_nick/name internally.

...in which case it belongs in glib.

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: new stock icons

[Morten Welinder]

On 4/2/07, Jakub Steiner [EMAIL PROTECTED] wrote:
 Hi gtk+ developers.
 I propose a replacement of the current gtk stock icons with newly
 created artwork[1].

True or False: if you do so, applications that use the occasional own
icon will en up looking wrong with the new icons.  (And if we fix the
icons, then the updated look with be wrong with old gtk.)

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list